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 > no sprites in Doom/Wolfenstein?

#19104 - darknet - Sun Apr 11, 2004 9:50 am

Frequently, I like to take my cartridges and put them on the computer so I can fire them up in VisualBoyAdvance and hopefully get a glimpse into how the professionals structure portions of their game.

Which brings me to my question...

Upon playing both the Doom and Wolfenstein GBA ports, I noticed that if you check the OAM entries, they all appear to be blank.

I know the people at ID have some crazy crazy code (as Carmack is known for in particular), so I see that their work on the GBA might be no different.

Does anyone know how to got away with not using OAM (if that is the case). Furthermore, I noticed that Doom was operating in mode 4! woah! I guess if they truly are not using OAM, that is the best thing to do...

Just thought I'd ask and see if anyone else has noticed...

-Mike

#19108 - Lupin - Sun Apr 11, 2004 1:39 pm

Well, they have some good programmers on ID software. I think they are using mode 4 because it has a backbuffer and if you take a look at the colors of the game you will notice that it doesn't use too much of them :)

I think they are not using OAM because you can only draw 64x64 (or 128x128 if scaled) sprites and when the enemy comes very close it might fill out half of the screen. They can draw everything without hardware sprites because of the mode 4 backbuffer, it allows rendering on low frame rates (in mode 3 you would have to draw 60 frames per second, otherwise you might get shearing)
_________________
Team Pokeme
My blog and PM ASM tutorials

#19112 - poslundc - Sun Apr 11, 2004 3:29 pm

I imagine they didn't use hardware sprites because of the severe limitations of the hardware when there are a lot of scale/rot sprites involved.

Basically, you only get 1,210 cycles worth (less if you want to manipulate sprites in HBlank) of sprite-processing per scanline. Normal sprites take one cycle per pixel, but scale/rot sprites take 26 cycles every 8 pixels.

So if you had a 64x64 sprite scaled up to 128x128, it would take 416 cycles to process each scanline, or more than a third of your available resources. Once you run out of cycles it stops displaying sprites. In a game like Doom, where you constantly have enemies getting very close to the camera, you could easily wind up with most of them not displaying properly.

Still, I'd have thought they might have used the sprites for certain fixed (not to mention unscaled) elements, like the player's weapon, and the status layer.

I'm currently working on a piece of software that helps to circumvent this hardware limitation by doing some fast scaling in software, so that you can turn off the scale/rotation flag and get single-pixel processing when you need it.

Dan.

#19113 - Lupin - Sun Apr 11, 2004 3:33 pm

poslundc wrote:
Still, I'd have thought they might have used the sprites for certain fixed (not to mention unscaled) elements, like the player's weapon, and the status layer.


they do.
_________________
Team Pokeme
My blog and PM ASM tutorials

#19115 - tepples - Sun Apr 11, 2004 4:04 pm

It has little to do with the number of sprite drawing cycles per scanline. The big killer that prevents games using raycasting (Wolf3d) and BSP (Doom) style engines from using HW sprites for even small actors is that walls in front of the player are drawn on the same layer (layer 2, the only visible layer in mode 4) as walls behind the player. Therefore you can't stick a HW sprite between a back wall and a front wall the way you could in modes 0-2.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

#19117 - poslundc - Sun Apr 11, 2004 4:25 pm

Ah, yes, I keep forgetting we're talking about Mode 4... :P

Dan.

#19121 - Lupin - Sun Apr 11, 2004 4:51 pm

oh yeah, i think tepples got the point :)
_________________
Team Pokeme
My blog and PM ASM tutorials