gbadev.org forum archive

This is a read-only mirror of the content originally found on forum.gbadev.org (now offline), salvaged from Wayback machine copies. A new forum can be found here.

Coding > Game is REALLY slow

#6516 - MumblyJoe - Wed May 28, 2003 6:38 am

I have been working on a version of frogger and it runs so slow that it is sad.

I am using mode 4 and software-based sprites with double buffering and I have seen projects that are alot bigger than mine with the same modes run much faster.

I recently changed the way I was compiling it to:

Code:
g++ -c -O3 -mthumb -mthumb-interwork Frogger.cpp
g++ -mthumb -mthumb-interwork -o Frogger.elf Frogger.o

objcopy -O binary Frogger.elf Frogger.gba


and now it runs about twice as fast but is still very sad to watch.

Can anyone suggest if I am just compiling it wrong or if there is anything else I should do.

Note: I am using DevKitAdvance and am not using Jeff F's crt0.s (would that help?).
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!

#6518 - Quirky - Wed May 28, 2003 7:50 am

Quote:
I am using mode 4 and software-based sprites with double buffering


Eeek! Why? :)

Surely the simple tile-based screen of Frogger, coupled with the GBA's hardware sprites makes this an unusual approach.

Unless it's all in 3D or you are planning on porting it as is to the GP32, by far the best option for speed would be to switch to using mode 0, 1 or 2 and use hardware sprites.

#6519 - MumblyJoe - Wed May 28, 2003 8:32 am

I basically made the choice because of the simplicity of writing it, considering I have written games with the similar "everything is in a loop with no interrupts and treats the screen as a bitmap" style.

Regardless, its too late now, I have virtually finished the game and would like to see it run faster.
_________________
www.hungrydeveloper.com
Version 2.0 now up - guaranteed at least 100% more pleasing!

#6522 - Sweex - Wed May 28, 2003 9:36 am

Quote:
"everything is in a loop with no interrupts and treats the screen as a bitmap"


Well, that is basically the problem! The GBA isn't really suitable for this approach. It will work, and it is possible to get some speed out of it, but hitting 60fps (or even 30) is not really easy!

One thing I can think of is doing memcpy's (which you're probably using) with DMA. And you can still use hardware sprites in mode 4!

#6533 - niltsair - Wed May 28, 2003 2:55 pm

I only tried to do a transparency effect in mode 3 between 2 bitmaps (one slowly appearing on top of the other) and boy is it slow :) I would get a frame per 1 second. I think i could get it to work to a decent speed by writing it in assembler, something i've yet to try.

So, i don't know about compiler's options optimisation to speed up your code, but writing your inner loop for drawing in Assembly would greatly help. And also to transfer data with DMA as previously mentionned,

#6535 - Jason Wilkins - Wed May 28, 2003 3:19 pm

Using Jeff's crt0.s and lnkscript will not help at all. cr0.S and lnkscript affect the initialzation and layout of the rom and have no effect on speed in the slightest (except that Jeff's crt0.S might cut a millisecond or two off of your startup time, get out your stopwatch ^_^).
_________________
http://devkitadv.sourceforge.net

#6545 - Maddox - Wed May 28, 2003 6:42 pm

Make sure you're not using floating point numbers. They are just too slow.
_________________
You probably suck. I hope you're is not a game programmer.

#6547 - hzx - Wed May 28, 2003 7:06 pm

Hi. I am quite new in GBA development, but I have already learnt that good performance can be taken by optimizing your code, which doesn't mean you have to code in asm. First of all, set your emulator properly. It took me a week to figure out, that a problem I met was not in my code but in the emulator - it used frame skip 1/3.

Use DMA to clear screen or copy sprites. Try to optimize your routines. Don't use x*160+x/2 to calculate the pixel position in mode4 - use ((y<<7) - (y<<3)) + (x>>1) instead. For this mode I wrote 2 routines - a slow but accurate one, with the necessary memory read, and one, with 2 color parameters if the background color is known, etc.
_________________
.hzx


Last edited by hzx on Thu May 29, 2003 8:18 am; edited 1 time in total

#6549 - jenswa - Wed May 28, 2003 7:29 pm

One little remark, don't trust you emulator,
the more the better approach of reality, but even better
is to try the rom on the real hardware (gba).
I had some stuff running fine on the emu, visualboyadvance,
I slowed some things down to get it to the right speed on the emu,
than I tried it on hardware and it was slow,
so it's not a good approach for comparing speed.

Also, mode 4 is a little slow, but some hardware sprites over a
nice bitmapped background is just nice.
If you still want to use mode 4, I would do that.
_________________
It seems this wasn't lost after all.

#6552 - Jason Wilkins - Wed May 28, 2003 8:28 pm

Maddox has shown me the light! Next time I'm late, I will blame floating point!
_________________
http://devkitadv.sourceforge.net

#6570 - MojoJojo - Thu May 29, 2003 11:35 am

You are using dirty rectangles aren't you? That is, only redrawing the parts of the screen which you've plotted your sprites too? Not clearing the screen every frame and redrawing it all?

That's the only thing which I can think of which would make a much of a difference to performance, without changing over to using hardware sprites. Which is what you probably should do.

#6578 - Maddox - Thu May 29, 2003 6:18 pm

Hallelujah!
_________________
You probably suck. I hope you're is not a game programmer.