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.

DS development > crash on glTranslate* [SOLVED]

#164429 - JYC376 - Sat Nov 01, 2008 7:09 am

So my 3d game has this really strange bug where if I try to call glTranslatef/glTranslate3f32 in a certain part of my code, it would freeze...Same goes with the glRotate* and glScale*

I know that I'm inside the 16-cube, and I'm not pushing too many matrices, because if I don't call any of those functions it won't crash.

...Anyone had the same problem?

If someone wants to check out the source: n-echo_src-10-31-08.zip - 0.18MB

EDIT: PUT THE APPS FOLDER AT ROOT AS WELL!

The offending function is draw_character in echo_gfx.cpp (line 185). It should crash with the first glTranslatef (before drawing the square), but it will work with just the last glTranslatef (at the end of the function) or no translate at all.

????

Thanks.

Last edited by JYC376 on Sun Nov 02, 2008 5:56 am; edited 1 time in total

#164445 - elhobbs - Sun Nov 02, 2008 12:04 am

I did not have a problem with glTranslate but I did have problems with the menu drawing code in main.cpp on line 683 - here is the change I made
Code:
while(each_file < files->num_files)//NUM_FILES_DISPLAYED)
I also added
Code:
defaultExceptionHandler();
to the main function. this dumps the registers on an exception - you can then use PC and LR and the map file to see where the exception occurs.

#164448 - JYC376 - Sun Nov 02, 2008 5:57 am

Thanks for solving that loader bug!

Anyways, this glTranslate bug ended up being from both Tinyxml and the amount of vertexes I was using...I have to cut the amount down then.

#164452 - elhobbs - Sun Nov 02, 2008 5:06 pm

I have never had the ds freeze from too many vertices. the rendering will get all screwy - skipping triangles and some other odd artifacts on the screen, but no freezing.

#164453 - JYC376 - Sun Nov 02, 2008 6:39 pm

elhobbs wrote:
I have never had the ds freeze from too many vertices. the rendering will get all screwy - skipping triangles and some other odd artifacts on the screen, but no freezing.


Well, apparently I jammed it full...

Or I have a weird memory bug. But it was solved when I stopped drawing so many vertexes

#164456 - silent_code - Sun Nov 02, 2008 8:33 pm

I say it's a bug, not the hardware. I have ... well, "stressed" it many times and the only "reward" I got was 6 hz rendering (not from rendering, though - this is impossible, I guess... even in immediate mode rendering, I haven't reached below 30 hz, yet) and geometry disappearing, like it should.

No freezes - ever!

Fixing it by reducing the data set is probably an indicator for a memory management (or the lack of it, depending of the implementation) related bug.
_________________
July 5th 08: "Volumetric Shadow Demo" 1.6.0 (final) source released
June 5th 08: "Zombie NDS" WIP released!
It's all on my page, just click WWW below.

#164493 - JYC376 - Tue Nov 04, 2008 4:13 am

silent_code wrote:
I say it's a bug, not the hardware. I have ... well, "stressed" it many times and the only "reward" I got was 6 hz rendering (not from rendering, though - this is impossible, I guess... even in immediate mode rendering, I haven't reached below 30 hz, yet) and geometry disappearing, like it should.

No freezes - ever!

Fixing it by reducing the data set is probably an indicator for a memory management (or the lack of it, depending of the implementation) related bug.


As much as I hate to admit it, you're probably right. Well, back to Valgrind =(.

TinyXml has also been acting strangely, with bad_alloc errors popping up...I'll probably switch to RapidXml

#164497 - kusma - Tue Nov 04, 2008 10:23 am

sounds to me like you're dealing with good old memory starvation...

#164512 - Cydrak - Tue Nov 04, 2008 10:17 pm

I guess I'll chime in and say that heavy scenes are fine here, too.

It *is* possible to kill the GPU, though. What seems to do it is dangling vertices: having an "open" poly when you call glFlush(). After that it freezes hard, and future gl*() calls will wait forever (search GBAtek for SWAP_BUFFERS).

There are several ways to manage this--corrupt display lists, soft-booting the DS from an interrupt whilst drawing... I guess generic stack/memory bugs too. But with those you're likely to hang yourself anyway...

JYC376 wrote:
TinyXml has also been acting strangely, with bad_alloc errors popping up...I'll probably switch to RapidXml

If you know you're within RAM limits, bad_alloc can be a sign of heap corruption. I've gotten that before. :/ (That, or it's just really bad fragmentation, since there is only 4MB, and with no virtual addressing, the data can't be moved.)

Also, you may already know this, but watch out for your stack, it's slightly under 16K... any libraries that play fast and loose with local arrays could die all too easily. Reasonable recursion should be fine, so long as there aren't any large C++ locals/temporaries causing stack bloat...