Search results

I have this small test program: mode7.fxe Display is initialised with this: GpGraphicModeSet(8, NULL); GpLcdSurfaceGet(&gpDraw[0], 0); GpLcdSurfaceGet(&gpDraw[1], 1); An frames are flipped using this. GpSurfaceFlip(&gpDraw[db] ); No clock speed change.

No problem, I can do that :) Also I wanted to know: do all the apps that were compiled with the official sdk work ??

oh.. ok :) Thanks

Yes but I meant for an actual second. I know that it's a 1/64 timer, so it will be called every 64 ticks... But are those ticks 1 millisecond ???

Just a little question... How often is the interrupt called using rTICINT = 0x81; ???

Hi again ! And thanks for your comments !! Just a little new post to tell you that I updated my website, with now a SmashGp page with screenshots, and a download page with all the characters ready for use (including a fixed version of sonic 0.2). matkeupon.gp32z.com

Hi there !! I continued working on SmashGp, as a lot of stuff were still missing. Now the gameplay should be closer to the original N64 version. And what I realized a few days ago is that now, when I'm testing, you can hear me laugh from a distance :) So for the quick changelog: -New...

You can add attachments to your posts. Send your pictures and I'll try to figure it out.

In fact, you'll have to rebuild the virtual smc file each time you change a sprite or a move, but that's faster than transferring the chr and pak files each time to the gp32.

If I'm not mistaken the memcpy is directly written in asm, so it's obviously faster than any c routine. Your c code inside the loop can be reduced to one line, and it won't make the compiler use ldms, nor copy 32 bit chunks.

You can also ask directly your questions in here, that's why the topic is there :) I'll try to update the guide soon, as the guide now is not really helpful, but it takes a lot of time. By the way, I've finished Luigi, and I'll release it with the 0.3 version, which should be soon.

Sorry watoto, but the 0.3 version won't load external tilesets yet... But the next should. By the way, I can release a GeePee32 version of the game with a pre-built smc file, for testing purposes.

True. GeePee32 is fairly inaccurate regarding speed and it's results are variable. Well, I'm not sure this method is faster than a memcpy... This is a very simple and non optimized one. But I don't really think you can do better than memcpy on that (and the same problem appears here, you can't...

The problem is that the 640x480 picture will not fit in the framebuffer !!! And if you set the framebuffer to the picture data, then it won't appear correctly. You need a good clipped 16 bit blitting routine. The Una-i (I think it was called like that) library should have fast ones.

Could you provide your loop with the display code ??

This is true, but there are 2 more reasons: First, there are alignment problems also (which is not that bad), and the fact that your gif will have to be 240 pixels (tall / wide, it depends if you rotate it or not) if you want it to be displayed correctly. So IMO it's not a good idea. Try to use...

Yes, I think I'll use my tileset system from GpFinalWar here too, that way you'll be able to change the tileset. The problem with Mappy (and the background map) is that Mappy often exports the maps with another array following the map in the TXT file. So you should open your .TXT map files...

:) ;) B)

Great :) I like Coolspot too, but the only coolspot game I ever played was on Amiga and it sucked... So that's cool to see Cool spot on a smooth game :P Also, I'll release 2 new characters before the end of the month.

Yep that's easy. You have to wait between flipping frames, the GpSurfaceFlip() command is not waiting enough. If you wait for about 15 ticks, then the flickering effect should be gone.