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.

Graphics > yeti3d hangs

#15601 - cesium - Mon Jan 26, 2004 12:46 am

The awesome yeti3d team wrote:
Quote:
NOTE: There is a GBA timer bug that causes the engine to freeze after ~2 minutes. The bug has been fixed and I'll upload a new demo soon.

I am finding that the demos created using the GPL'd code also hang
after about 2 minutes.

Does anyone else have a problem with yeti3d hanging?
Will the fix be rolled into the GPL code?

Cesium

#15602 - Tim - Mon Jan 26, 2004 12:50 am

I couldn't get the Temple demo to work on my flashcard for some reason, I just got a black screen.

I think they've got rid of the bug which hangs it when you press Select, though.

#15603 - cesium - Mon Jan 26, 2004 2:40 am

The hang when pressing select is not really a bug. This is the main loop:
Code:
  while (!yeti.keyboard.select)
  {
    <code removed for brevity>
  }
  return 0;

so pressing select just stops the app.

Does anyone know how I can learn to put various entities in my levels
using the yeti editor?

How then do I implement the behavior of an entity? I see a routine called
guard behavior, do I just implement an analogous set of routines?
What about power-ups?

Also, how do we dynamically alter wall/floor heights at run-time in
order to implement secret stuff/elevators etc?

I'm totally new to FPS programming (though not to programming) and a reference to a tutorial would
be much appreciated.

Cesium

#15622 - Derek - Mon Jan 26, 2004 9:05 am

The fix is very simple. In main.c replace the timelag macro with:

Code:
#define timelag() (s16)((*(volatile u16*)0x400010C) - real)


The GPL timer code stupidly uses two timers, since it was based on other source durring a time when I didn't understand GBA timers myself :-)

I now only use one timer which is more accurate. The GPL code is really only useful if you are learning how to write fast texture mapping or fix point rotations. This style of code is very rare these days. A lot of older DOS forums have vanished from the internet.

The GPL rendering is far too dark. I received a flashcard 3 days ago, so I only just saw this stuff running on a GBA. The Gamma has been fixed, so I'll get a demo out soon.

I'm thinking about releasing a second GPL version based on the latest code which has enough features for a TombRaider or a Red Faction. Perspective correct tmapping is done. Everything required for a RF is written.

http://www.n-gage.com/R1/en/games/games_red_faction.html

Maybe a shareware version is the go (?). What do people think? What about a 3D API released with HAM?

Derek Evans - Yeti3D Author
http://www.theteahouse.com.au/gba/

Last edited by Derek on Mon Jan 26, 2004 1:53 pm; edited 1 time in total

#15624 - Derek - Mon Jan 26, 2004 9:32 am

While on the topic of Yeti3D's future.

On the back of my GBA is a copyright date of 2000, mmm, but its now 2004 (!) and all Nintendo seems to be offering is:

1) A new double screen device with no guaranteed GBA/GB support.
2) Some kinda "China Only" all in one play thingie.

Whats up with that! Do theses remind you of geek toys from the late 80's, or am I just too far into my 30's.

Where is my GBA with everything a GP32 has! If nintendo leaves it too long, you will see a Sony device emulating GBA games.

I knew the Amiga was dead the day I could emulate the hardware faster on my PC.

That day will soon come for the GBA unless Nintendo upgrades the hardware. We dont need a new platform!

BTW: Yes, I want a keyboard attactment and touch screen as standard. Beleive it or not, kids like todo more than just play old platform games.

Derek Evans

#15635 - cesium - Mon Jan 26, 2004 7:56 pm

Derek,
Thanks for the reply. I'll try that timer fix when I get home tonight.

As far as the GPL code goes, I'm using it to demonstrate an alternative
hardware interface to the GBA other than the usual buttons. I'll bring in
the hardware interface through the external serial port on the back.

This way I can throw together a proof of concept pretty quickly.
Thank you for the GPL.

Any tips on implementing entities? Power ups? etc?

Thanks!
Cesium

#15642 - Derek - Mon Jan 26, 2004 11:47 pm

Thats cool.

Entities are done, although incomplete in the GPL version. You call yeti_entity() to grab a entity pointer from the entity pool.

If you look in game_init() you will see code which iterates the map and creates entities for each cell based on the entity id which is programmed by the Yeti3D editor.

Basiclly, you add more ID's for each entity type. The latest version has a ton of these for trees, scrubs, monsters, pickups, exit points, transporters, overpath bridges, chairs, candles, pots, boxes, etc etc.

I have xxx_init() functions for each entity plus "behaviour" callbacks. You also have onhit() events for each entity to detect collisions. ontick() events are used for AI. The latest code also has entity-to-world collision callbacks plus a global entity-to-entity callback which is avaliable if you want to override the default "simple" collision detection code. On faster platforms, you can use full sphere-to-sphere collisions. The default is box-to-box.

The latest code also supports switchable MD2 rendering & more sprite blending effects.

I'll see if I can release a new version soon. If I decide to release, I want to make sure the code is perfect to prevent any incompatiblities between ports.

Other new features include the terrain & cell warping code which allows for some very cool worlds. I also have some invisible cell collision variables which provides collision detection for static entities. This is a lot faster than the entity-to-entity code which bogs down with increasing numbers of entities.

So, basiclly you can jump on trees or boxs, or create platform/bridges which allows players to cross over in mid air. Cool stuff.

Derek Evans
http://www.theteahouse.com.au/gba/