Fast Pixel And The Question How To Access Time And Variables
Posted 03 February 2008 - 03:18 PM
i tried to do fast pixel output on the cp330 screen. so i stepped over the posts and finally i found the post about maze3d: http://www.cpsdk.com...wtopic.php?t=67
i took a look at the code, and checked how he gained access to the classpad-screenbuffer.
it is done via invoking a so called hidden-function to get to the screen-buffer.
so with this knowledge i wrote yesterday the base-structure of a calculator-engine system, just short "ce". it uses namespaces to seperate several areas of handling, like graphic or keyboard, network, etc.
the desing is fully abstract and so it is possible to support the hardware of different types of calculators or if you want computers.
code of course has to be written to fill the namespaces.
at the moment i have concentrated on graphics an i got a simple system, where the virtual graphic-device of the classpad initializes the system specific components for graphic. the access to screen is abstracted via rendertargets. so default is, that the current rendertarget is the actual screenbuffer. but if you are smart you create a colorbuffer, do the full rendering in there and copy the whole colorbuffer to the screenbuffer of the classpad. for this last step, every device holds a virtual function "flush" which overtakes the "current setting" to the device.
at the moment it is only possible to draw 8 pixel at once(1 bit per pixel), because i have not finalized the generic access to rendertargets to support different rendertargets with different formats.
if the buffer-access handling works, i will take a look to handle depth-buffering and how it incorporates with colorbuffer. if you only want to write color to colorbuffer if the pixel is in front of others these information have to be exchanged.
the whole other hardware capabilities can be implemented in other devices, for example keyboard device or so.
the tree is: device_interface::device_area_interface::device_system
area := graphic|keyboard|sound|...
so for now it is a project compiled with the cpsdk. for renderig a window has to be created and then invalidate, begindraw, enddraw from peg has to be called. between begindraw-enddraw you can flush the colorbuffer to screenbuffer.
at the moment im interested in performance so i want to determine the pixel-fill rate of the device and my implementation.
but to do this i need access to a timer and the possibility to write elapsed time to a classpad variable.
does anyone know how to this?
because hidden-function access only works if the programm is compiled purely for the classpad it is possible to emulate the drawing capabilites with a virtual device based on gdi or what ever. a code-path selection has then to be set, of course.
if i can manage the data handling of the render target, i will post the small-framework so that everyone can use it an make it better, or perhaps something already exists. then let me know
there exists a function in the bios.lib: _CP_Btime_GetTime_RtcMandS
seems to access the the realtime-clock, but i don't know the parameters; anyone?
Posted 03 February 2008 - 09:24 PM
i think this is a rather low value. i just painted a quad of 10x10 pixel and let it run around the border of the screen. every frame it made one pixel-step forward.
i counted the seconds until it reached its origin. so of course there is something like logic which slows down the result but i think this shouldn't matter.
i assume with batch-pixel output - is this a 32bit processor? - it is possible to get a bit more speed. for example a 8x8 quad can be drawn with only eight draw calls. i used 100 draw calls for my quad in the test.
i have to say that i copied every frame the whole color-buffer to vram, so from this point of view i would get <=7296000pixel/second which would mean i would get nearly 20fps if i draw the whole screen once per frame.
so anybody got similar or better results?
Posted 04 February 2008 - 12:38 AM
the benchmark renders 1000 random moving black boxes with each a size of 10x10 pixel and a horizontal moving white box.
the white box is my "tracer", so i count the seconds the white box needs to go from one side to the other.
to get along it needs 150 frames(i call it one pass) because every frame every box make only one step in one direction, but also possible in both directions, except the white box.
to know that you have a framerate of 20fps the tracer has to take 7500ms for one pass, because 20fps equals 50ms. you have 150 steps; so 50ms/step * 150steps = 7500ms.
so my results for one pass:
cpp330 @ default speed: 30000ms
-->benchmark running @5fps
1001 * 100pixel * 150/30000ms = 500.5pixel/ms equals to 500500pixel/s
so you can handle at 20fps 25025pixel, which is equal to an overdraw of factor 0.65
cpp330 @ double speed: 15000ms
-->benchmark running @10fps
1001 * 100pixel * 150/15000ms = 1001pixel/ms equals to 1001000pixel/s
so you can handle at 20fps 50050pixel, which is equal to an overdraw of factor 1.3
to overclock the classpad i used exec speed.
while writing the post, i decided to call the benchmark "1001".
for sake of interest, i uploaded exec-speed and 1001. you can find them both right here:
to quit the benchmark press first the "keyboard"-key and then the "menu"-key.
for myself i'm interested about other benchmark results, although you have to count the time by yourself.
to make it better i would like to write in variables which can be viewed via classpad, so that it can also be possible to make a statistical evaluation or so. just to make clear that i still need answer to the question how to access variables.
for the timer problem i found a library, which implements sh3-timer functions. so time measurement should be possible within classpad.
and before i forget: does anyone know something about getting more speed then the double from classpad? i already read that this is possible but not safe, so it's true?
if it's safely possible, than you could get possible more frames and possible better rendering.
i wish good night and 1001 dreams
Posted 04 February 2008 - 02:09 AM
People have experienced problems changing the CPU speeds of their ClassPad just to warn you, so do this at your own risk.
The ClassPad uses a SuperH 3 processor. I suggest looking around on Google for more information.
Posted 04 February 2008 - 09:50 AM
also i could not find any information about the function table of the bioslib.lib. can anybody help?
is the display also controlled by the dsp?
and the last one: what exactly is the problem at higher speed? double speed seems to be save, so what's going on at higher rate?
i speeded things up, but also changed the size of the rectangles to 8 so that a h-line of a box can be plotted at once.
got nearly 40fps @ single speed.
...and 80fps @ quadruple speed.
so i think the bottleneck is my oo-code or the dsp-bus is busy at maxium. i also discovered a maximum usefull number of indirected function calls. if used more than the performance drops immediately - perhaps the cache reaches its limit or the mmu is overpowered. but this has to be examined further.(perhaps the compiler messes things up)
so again, for jumping boxes go here: http://home.arcor.de.../Casio/1001.cpa
warning: clear-button will adjust 4-time speed, back-button normal speed and the setting will be hold after exit. i have to change the controls if i find out the other keycodes.
the more comparative benchnmark to the old 1001:
nearley 1.3 times more pixel output and runs 4times faster.
Edited by kucalc, 05 February 2008 - 08:52 PM.
Use EDIT to combine your post
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users