forums.ps2dev.org

[nonarKitten]

I don't know how much overhead there is in LUA itself (i.e., how much critical optimization in the C functions would actually help), but skimming through the code I can see a lot of places where there's a lot of cycles burnt.

1. Because you're using both VRAM and system RAM for graphics, you have to needlessly check everytime whether-or-not the operation is being performed against the screen (into VRAM) or against something else (in system RAM). Considering it has 2MB, isn't it being a little restrictive using it exclusively for the ~256KB frame buffer? It would be a lot faster to just use VRAM exclusively, and just have an error if the user tries to load more graphics than memory permits.

Either that, or go the AMOS/Darkbasic way and start making more libraries that use and manage VRAM themselves (like sprites with collision detection and scrolling tilemapped playfields).

2. Every single graphics command, including pixel() is bounds checking. While this is the safest practice against novice programmers, it adds a lot of overhead (e.g., compare filling the screen with fillScreenRect versus doing it a pixel-at-a-time within LUA). Perhaps a Blitz like FastWitePixel and FastReadPixel function could be made that does not do this and only draws to the screen (to also avoid the overhead of that test).

3. Unless perfectly optimized, MUL and DIV should be avoided at the top loop in drawing functions. For example, in fillScreenRect, instead of doing a PSP_LINE_SIZE * whatever each pixel, you calculate the pixels skipped per line (which is the image width minus the rect width).

[chaos]

some great suggestions, makes me want to compile my own version of luaplayer. :)
_________________
Chaosmachine Studios: High Quality Homebrew.

[Shine]

1. Yes, using VRAM is a good idea, feel free to enhance the graphics functions to cache images in VRAM :-)

2. The check for valid x and y position are very fast compared to the conversion from double to int when calling the function from Lua (every number in Lua is double), so this is not very much faster.

3. I've optimized it, but it looks like it is only faster when accessing main memory, but when accessing VRAM it is not faster, perhaps because VRAM is not cached, so the CPU waits mainly for memory access and the calculation doesn't hurt. But accessing the main memory is now twice as fast.

Your draw line function is not very much faster, about 15 %, but I've included it.

4. poke and peek would compromise the security, so I don't add it. And it would be not faster, because the double numbers has to be converted the same way as in pixel(x, y, color).

5. loadmodules could compromise the security, too.

[nonarKitten]

I'd love to try compiling my own version for experiment, but haven't quite figured out how to do so on my Mac just yet.

Edit: I've read somewhere that double-precision really hurts on the MIPS3 architecture. It might be beneficial to go to single, if possible.

While integers might be better for somethings, fp mul and div are faster than integer mul and div. Where they're used may affect speed (for example it may be better to multiply the Y with PSP_LINE_SIZE as a float before converting to an integer.) e.g., (my C memory is rather rusty, so I can't say if this is correct or not).

[nevyn]

[nonarKitten]

Ye haw! Got it working - now I can profile all my wacky ideas before bothering anyone. Thanks! Svn is the key - get's everything I need all at once instead of compile-what-am-I-missing-go-get-and-recompile...
_________________
"Knowledge without wisdom is like a bunch of books strapped on the back of an ass."

[Shine]