| Author |
Message |
|
vecna
|
A few questions about sprites and lineints...
 Posted: Mon Mar 27, 2000 9:10 pm
|
Well, I'm on spring break now, and have finally had some uninterrupted time to hack away at my emu. In two days, I've really made a LOT of progress. I've almost got my emulator running great - I'm getting ready to tackle sound, currently working on the GUI, have save/load states in, SRAM, etc., and VDP emulation is practically done. I've got two main remaining glitches. First of all, I've got a problem with "ghost" sprites. Some games are worse than others, but almost all suffer from it in SOME form. I guess the problem is that there's some way to determine if a sprite is 'Off' or not, but I have no idea what this is. Charles Mac Donald's excellent VDP docs state that the sprites are drawn backwards from the last sprite OR the last sprite with a Y value of 208. I'm not quite sure what is meant with this. What is the 'Or' in that sentence? :) I tried literally starting the sprite drawing from the first sprite with an actual Y ofs of 208, but it didn't solve the problem in most games, and some games [Rastan], the sprites don't show up at all. Is there something I'm missing? Any help would be greatly appreciated.
Also, my lineints are 'messed up' but beyond that I can't really specify. Hangon works '90%' right, Choplifter is completely FUBARed, the intro to Quartet *tries* to work but ends up just sort of flashing. Is there any behavior to this besides VDP REG #10 specifying the number of lines between lineints? I understand that this is probably the area of the VDP that is currently least understood, but what behavior are you other EMU authors using to get stuff to 'pretty much work?'
Oh, one last thing. I've not yet investigated this really, so I'm not sweating it yet in that I'm not stuck, but some games simply refuse to boot. Psycho Fox, Power Strike, Parlour Games are some that I've tested. My current wild guess is that this is because I've not implemented any of the language detect stuff or any ports beside VDP and control ports basically. But, is there anything else I should be aware of?
Ah well. *Any* help at all would be enormously appreciated.
|
| |
|
- Joined: 24 Jun 1999
- Posts: 1732
- Location: Paris, France
|
Posted: Tue Mar 28, 2000 5:36 am
|
I'll be short to answer. In your situation it's hard for us to help you with anything.
Basically considers your emulator still suffer from a hundred of bugs (don't worry it's normal :), and that's why not many games are working.
But you will very probably fix most of them (and the more importants) in a short period of time, then problems will be more specific and discussable about!
As for Charles' Doc, they covered everything needed to get a near perfect SMS/GG vdp emulation.
Good luck!
As for Psycho Fox, it was the first game to run under Meka.
At my knowledge no game requires to run on a certain country system, so that shouldn't be a problem.
|
| |
  
|
|
Nyef
|
Posted: Tue Mar 28, 2000 11:06 am
|
Quote > Well, I'm on spring break now, and have finally had some uninterrupted time to hack away at my emu. In two days, I've really made a LOT of progress. I've almost got my emulator running great - I'm getting ready to tackle sound, currently working on the GUI, have save/load states in, SRAM, etc., and VDP emulation is practically done. I've got two main remaining glitches. First of all, I've got a problem with "ghost" sprites. Some games are worse than others, but almost all suffer from it in SOME form. I guess the problem is that there's some way to determine if a sprite is 'Off' or not, but I have no idea what this is. Charles Mac Donald's excellent VDP docs state that the sprites are drawn backwards from the last sprite OR the last sprite with a Y value of 208. I'm not quite sure what is meant with this. What is the 'Or' in that sentence? :) I tried literally starting the sprite drawing from the first sprite with an actual Y ofs of 208, but it didn't solve the problem in most games, and some games [Rastan], the sprites don't show up at all. Is there something I'm missing? Any help would be greatly appreciated.
Well, what I do for sprites is I start searching through the sprite array until have either N sprites that are visible (I think N is 4, but I don't remember offhand), or I have seen a Y coordinate of 208. The visible sprites are stored in an array somewhere. I then go through my array, and draw them in reverse order.It seems to work for most games.
Hope this helps.
--Nyef
|
| |
|
- Joined: 28 Sep 1999
- Posts: 1197
|
Posted: Tue Mar 28, 2000 3:20 pm
|
Quote > Also, my lineints are 'messed up' but beyond that I can't really specify. Hangon works '90%' right, Choplifter is completely FUBARed, the intro to Quartet *tries* to work but ends up just sort of flashing. Is there any behavior to this besides VDP REG #10 specifying the number of lines between lineints? I understand that this is probably the area of the VDP that is currently least understood, but what behavior are you other EMU authors using to get stuff to 'pretty much work?'
I'd suggest writing to a debug log on what lines register #10 is
changed, and on what line an interrupt should be triggered. You can
then investigate the logs and make your own line interrupt rules.
Quote > Oh, one last thing. I've not yet investigated this really, so I'm not sweating it yet in that I'm not stuck, but some games simply refuse to boot. Psycho Fox, Power Strike, Parlour Games are some that I've tested. My current wild guess is that this is because I've not implemented any of the language detect stuff or any ports beside VDP and control ports basically. But, is there anything else I should be aware of?
You are not handling mirrored RAM correctly.
Most games write to FFFC-FFFF, then 'read' the value they
wrote from DFFC-DFFF or FFFC-FFFF. This is due to RAM being
mirrored, the bankswitch registers are not readable.
Other games to test this with are R-Type, Rampage, Time Soldiers,
and Wonder Boy 3.
|
| |
|
- Joined: 24 Jun 1999
- Posts: 1732
- Location: Paris, France
|
Posted: Tue Mar 28, 2000 5:23 pm
|
Quote >> Well, I'm on spring break now, and have finally had some uninterrupted time to hack away at my emu. In two days, I've really made a LOT of progress. I've almost got my emulator running great - I'm getting ready to tackle sound, currently working on the GUI, have save/load states in, SRAM, etc., and VDP emulation is practically done. I've got two main remaining glitches. First of all, I've got a problem with "ghost" sprites. Some games are worse than others, but almost all suffer from it in SOME form. I guess the problem is that there's some way to determine if a sprite is 'Off' or not, but I have no idea what this is. Charles Mac Donald's excellent VDP docs state that the sprites are drawn backwards from the last sprite OR the last sprite with a Y value of 208. I'm not quite sure what is meant with this. What is the 'Or' in that sentence? :) I tried literally starting the sprite drawing from the first sprite with an actual Y ofs of 208, but it didn't solve the problem in most games, and some games [Rastan], the sprites don't show up at all. Is there something I'm missing? Any help would be greatly appreciated.
> Well, what I do for sprites is I start searching through the sprite array until have either N sprites that are visible (I think N is 4, but I don't remember offhand), or I have seen a Y coordinate of 208. The visible sprites are stored in an array somewhere. I then go through my array, and draw them in reverse order.It seems to work for most games.
> Hope this helps.
It's fine if you don't want to emulate sprite flickering (which most people don't give a shit about anyway :)
|
| |
|
|
Nyef
|
Posted: Tue Mar 28, 2000 5:55 pm
|
Quote > > Well, what I do for sprites is I start searching through the sprite array until have either N sprites that are visible (I think N is 4, but I don't remember offhand), or I have seen a Y coordinate of 208. The visible sprites are stored in an array somewhere. I then go through my array, and draw them in reverse order.It seems to work for most games.
> > Hope this helps.
> It's fine if you don't want to emulate sprite flickering (which most people don't give a shit about anyway :)
Okay, I'll bite. How does sprite flickering work?
--Nyef
|
| |
|
- Joined: 24 Jun 1999
- Posts: 1732
- Location: Paris, France
|
Posted: Tue Mar 28, 2000 6:52 pm
|
Quote >>> Well, what I do for sprites is I start searching through the sprite array until have either N sprites that are visible (I think N is 4, but I don't remember offhand), or I have seen a Y coordinate of 208. The visible sprites are stored in an array somewhere. I then go through my array, and draw them in reverse order.It seems to work for most games.
>>> Hope this helps.
>> It's fine if you don't want to emulate sprite flickering (which most people don't give a shit about anyway :)
> Okay, I'll bite. How does sprite flickering work?
There is a limit of sprite per line. Sprites have to be drawn from 63 to 0 but the highest ones are not displayed on a perline basis if there are too much.
|
| |
|
|
Nyef
|
Posted: Tue Mar 28, 2000 7:30 pm
|
Quote > > Okay, I'll bite. How does sprite flickering work?
> There is a limit of sprite per line. Sprites have to be drawn from 63 to 0 but the highest ones are not displayed on a perline basis if there are too much.
That's what I thought you meant. Hence, scan from 0 to 63 until you have either hit the end (whatever form it takes) or obtained enough sprites. Then draw them in the opposite order to that which you found them in.
--Nyef
|
| |
|
- Joined: 28 Sep 1999
- Posts: 1197
|
Posted: Tue Mar 28, 2000 9:50 pm
|
Quote > That's what I thought you meant. Hence, scan from 0 to 63 until you have either hit the end (whatever form it takes) or obtained enough sprites. Then draw them in the opposite order to that which you found them in.
Actually, you need to draw sprites in the *opposite* order.
I think what happens is something like this:
Sprites are drawn from the first sprite to the last valid sprite,
and as soon as eight sprites are drawn that fall on the current
scan line, then all drawing is stopped.
I changed my rendering code around to match the above
description, and did some comparisons with a real SMS. The
flicker looked identical between the two, so I'm going to
assume this is the correct way to implement it.
A good game to test this with is Hang On, if you draw the
sprites correctly then the sprites used to mask the road
edges will hardly ever flicker, while the player characters
and signposts will.
|
| |
|
- Joined: 24 Jun 1999
- Posts: 1732
- Location: Paris, France
|
Posted: Wed Mar 29, 2000 5:56 am
|
Quote >>> Okay, I'll bite. How does sprite flickering work?
> > There is a limit of sprite per line. Sprites have to be drawn from 63 to 0 but the highest ones are not displayed on a perline basis if there are too much.
> That's what I thought you meant. Hence, scan from 0 to 63 until you have either hit the end (whatever form it takes) or obtained enough sprites. Then draw them in the opposite order to that which you found them in.
This is the case without flickering.
Now suppose sprite 50 to 63 are all on the same line (we'll call it line x).
0 to 49 are other sprites on other line(s).
The engine have to draw sprites 60 to 50 in this order, and not 63 to 53.
|
| |
|
