#2075 - asmodeus - Tue Jan 28, 2003 10:02 pm
Hi there,
I am fairly new to coding for the GBA and am basically having a play about with it to get a feel for what can be done.
I have been trying to create an isometric game a bit like Diablo but have been running into problems when the sprite moves behind a wall.
If there is only one sprite in the vacinity then I can simply adjust the priority of the sprite and the move tiles that obscure the sprite to a layer with the appropriate priority.
The problem comes when there are many sprites in the area. with the limited priorities on the GBA I end up with sprites infront of walls that should be behind them.
I have tried to rebuild the screen in modes 4 and 5 to see writting my own tiles onto a bitmaped screen is quick enough. sadly not. The obscuring problem is solved but the game runs far too slow.
I was wondering if anyone else has evet encountered a problem like this and if so have the solved it?
The onw way I can think of removing the problem is too overlay another sprite over each character which display the portion of the background that obscures the character. Whilst I can see this working it doesnt seem very nice to me.
#2083 - Maddox - Wed Jan 29, 2003 5:01 am
| Quote: |
| The onw way I can think of removing the problem is too overlay another sprite over each character which display the portion of the background that obscures the character. Whilst I can see this working it doesnt seem very nice to me. |
Yikes! Why on earth would you want to waste sprites with this idea. Just mask off the part of the sprite that's being occluded. That's 10 times better, maybe even 100 times.
_________________
You probably suck. I hope you're is not a game programmer.
#2095 - Quirky - Wed Jan 29, 2003 9:20 am
As you've probably realised, doing isometric games and using hardware priority tricks leads to severe headaches. If you look at Tactics Ogre, for example, the isomteric levels are simplified precisely because of this problem. You can never have the sprite/bg/sprite/bg problem on the levels they have there are no complex enough foreground "structures" and they use sprites for bushes and stuff.
I don't know how you can overcome it to make a truly open iso engine. Maddox suggestion is feasable but you'd have to have a mask for each tile describing which parts can cover your sprite and which parts can't. Then you'd have to do a check to see which parts are covering your sprite, etc, etc. It'd get messy quickly as you aren't in control of the background rendering pixel for pixel, but it is perhaps worth a shot? :(
#2096 - Splam - Wed Jan 29, 2003 10:42 am
One slowish and quite ram intensive way to do the masking is, while you're building the screen from isometric "blocks" you also create a depth mask (in ram). You build the screen from the back to the front and for each "depth" you store a value for the pixel that has been set 0-??? then when you place a sprite on screen you need to check that mask and via a calculation you get a minimum value for the sprite to be in front of, every pixel of the sprite that has a corresponding mask value LOWER than that value is masked off. This means you basically have to plot your graphics into each sprite + do the mask check which is what makes it quite slow.
There are of course other ways to do it but they all depend on the complexity of the level.
#2126 - Paradroid - Wed Jan 29, 2003 10:33 pm
Hi,
I spent ages trying to figure out how to do iso on the GBA - its a lot easier on the SNES. I'd recommend doing it in the same way as Knight Lore did on the Speccy. Use a character based background (for the floor, walls) and then make everything else in the scene using sprites. The GBA's got more than enough VRAM if you use dynamic sprites and then you can put all the sprites on the same priority layer - and you can still use the other layers for the score panel/effects. The sorting of the sprites then becomes a simple Y sort.
Hope that helps :)
#2131 - asmodeus - Wed Jan 29, 2003 11:09 pm
Thanks for the suggestions on this folks.
I think I'll give each of them a try :)
The storing of a depth mask seems to be an intereting optins since from what I can see it will allow me to make the levels however I want to.
thanks again for all your and if anyone else has any suggestions please let me know.
_________________
What does it mean "/bin/rm: command not found"?
#2135 - tepples - Wed Jan 29, 2003 11:31 pm
| Paradroid wrote: |
| I'd recommend doing it in the same way as Knight Lore did on the Speccy. |
I have never seen any Spectrum games; please describe what it does. How does it handle sprites going behind background objects?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#2138 - Splam - Thu Jan 30, 2003 12:07 am
afaik spectrum isometric games just used to redraw the screen and sprites each frame after sorting the objects, don't think they actually did any masking just overdraw. This was something the c64 couldn't handle due to the screen layout and (in a case like this) slower processor. The screen all tended to be 1 colour to save having to calculate colour attributes (and the fact that it looked awful sometimes). Also games would slow down considerably when more objects had to be drawn, don't think there would be enough ram to use the "mask" method which is another reason to think they just redrew everything.
Check out screenshots here.
http://www.cazzer.freeserve.co.uk/ultimate/knight.htm
#2153 - tepples - Thu Jan 30, 2003 5:44 am
So in other words, the rough GBA equivalent would be to draw each game object, even fixed objects such as walls, as a sprite and not to mess around much with background layers except possibly for the floor.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#2155 - Quirky - Thu Jan 30, 2003 8:44 am
That's the way the Batman remake posted on gbadev.org a few months ago (November I think) does it too, it uses the same model as knightlore did, it has a background for the very "far" walls then everything else is sprites. Z order is determined by sprite position in OAM. I recommend checking it out in VBA, as well as being technically a good example, it plays great too! :)
Paradroid, out of interest, why was isometric easier on the SNES?
#2160 - Paradroid - Thu Jan 30, 2003 10:21 am
You know how you need to store sprites in OAM in priority order (if you don't sections of the background layers get cut-out)? On the SNES you could store sprites incorrectly (so a higher priority sprite was in the list before a lower one - or the other way around, I can't remember now) and the hardware would cut-out the sprites for you. Look at some iso games on SNES emulators. They keep, say a lamppost outline (they don't need colour), as a sprite and draw it in the wrong order. As you walk behind it, it cuts out your sprite - easier to manage, no palette problems, fast and no priority hassles. I tried the same on the GBA but it cuts out the background, not the sprite. The GBA does have effects settings for cutting out sprites but they cut out every sprite rather than just ones higher in the OAM :(
After writing an iso game I'd go for KnightLore's/Batmans method every time. Much simpler, much easier collision, and you'll probably get a more fun game at the end of it.
#2161 - Quirky - Thu Jan 30, 2003 11:00 am
Thanks for that! I should have guessed at the sprite/bg priority thing. So if I understand it, on the SNES the individual sprite priority flags worked for sprite-sprite as well as sprite-background without any OAM order problem? I can see how that would help. It totally threw me the first time I came accross it on the GBA, especially as it's something the various emulators don't have and you only see it on hardware.
#2166 - Paradroid - Thu Jan 30, 2003 12:15 pm
No problem. The SNES did have the same problem as the GBA does - sprites MUST be in priority order in OAM to draw correctly, but the result of doing it 'wrong' is different between the machines. One cuts-out sprites (which is helpful), the other cuts out backgrounds (in a weird way and so pretty much useless).
I did have another way of doing iso, which was to find which background 8x8 tiles were infront of the iso sprite and OR those into another sprite. As you don't care about pixel alignment you can just copy the 8x8 character from the tile into the sprite and for a 56x56 pixel sprite, create a 64x64 pixel cut-out sprite and draw it offset. It's much the same as masking, but the difference being I could draw this new sprite on top of the iso one, with transparency set (as zero; ie totally transparent). The result being a cut-out (once the hardware reads a non-transparent pixel it stops), its fast as you are just doing an OR on aligned data so 32-bit accesses are possible (you only care about a non-zero pixels) and works with paletted 16 colour tiles for the backgrounds. Also means you can compress your sprite animations (eg LZ77) without having to decompress then every frame(or duplicate them). I tried it, without the transparency, and it worked really, really well. Still got the code somewhere I think if you're interested.
#2718 - Subway - Tue Feb 11, 2003 11:37 am
| Paradroid wrote: |
| Still got the code somewhere I think if you're interested. |
I'm new to GBA dev, too.
Please. :D contact@rogotworld.com
I can see now how I would do it, but looking at the code would be a great help.
Fredi