It is currently Fri Oct 20, 2017 12:16 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Fri Oct 30, 2015 12:37 pm 
Offline

Joined: Fri Oct 30, 2015 12:00 pm
Posts: 3
Hello.

I'm working on a project I have for the SegaCD videogame console, named "Alphaomega". It's about the character Miles "Tails" Prower being caught inside a graphical, artificial dimension and what has to do in order to go back to real world. The gameplay and level map style is meant to be similar as the old 16-bit Sonic the hedgehog games, but it has a bunch of ideas and concepts that doesn't fit to a Sonic the Hedgehog game, so Sonic isn't present for this game :P

I'm doing some drafts for a new level I'll get started with really soon, which for now I named as "Bitfield Zone". The goal here is to keep it, somehow, with a NES vibe to it.
Of course the Sega Genesis' video chip couldn't apply any post-processing effects to the final image (other than scanline-specific tweaks), but the least I can do is to implement this new art in such a way that looks visually accurate on screen, not only taking the color limts into account (which I need to be aware of yet!), but I'd also like to represent stuff such as a fake sprite limit, the color distortion (i.e. when some shading seem to appear like diagonal bar), etc.

What do I need to know?
Thank you!
EDIT: Grammar/Redaction


Top
 Profile  
 
PostPosted: Fri Oct 30, 2015 1:02 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10063
Location: Rio de Janeiro - Brazil
I think that NTSC artifacts would be difficult to simulate accurately, considering that the Genesis VDP has its own set of peculiarities that affect the video it generates.

But you could certainly make the video more similar to that of the NES by using the 256-pixel video mode, instead of the 320-pixel one. Use only 1 background layer, and try to approximate the colors that are available in the NES palette. You can even have real sprite flickering, if you place dummy high-priority sprites across the whole height of the screen to reduce the number of sprites you can actually use on each scanline.


Top
 Profile  
 
PostPosted: Fri Oct 30, 2015 1:16 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
The Genesis VDP can show 16 sprites and 32 slivers per line in 256 pixel mode or 20 sprites and 40 slivers per line in 320 pixel mode. The NES can show only 8 sprites and 8 slivers. So I'd guess the sprite limits can be simulated by putting six high-priority 32x32 pixel transparent sprites on each line with more than 8 sprites in order to eat up 24 of the 32 slivers, though that would also eat up most of your OAM. (The sprite display list in Genesis 256px mode has only 64 entries, as on the Master System and NES.)

But you probably won't be able to pull off a convincing diagonal bar distortion on a Genesis VDP. Its color burst lines up vertically, not diagonally, like the Master System screenshot at ccovell's page. Both a Genesis VDP in 256px mode and the NES/SNES PPU use the TMS9918 pixel rate of three pixels per two color burst periods. But the Genesis VDP keeps the 342 pixels per line of the TMS9918, compared to 341 for the Nintendo parts.

SG-1000, CreatiVision, ColecoVision, Master System, Genesis:
342 pixels per line * 2/3 color burst periods per pixel = 228 color burst periods per line
Because this is an integer, color artifacts line up directly below each other.

NES, Super NES:
341 pixels per line * 2/3 color burst periods per pixel = 227.33 color burst periods per line
Because this is not an integer, color artifacts line up diagonally.

Standard TV, by contrast, has 227.5 color burst periods per line, which produces an even checkerboard. If the NES or Super NES PPU added an extra master clock (1/4 pixel) to each line's horizontal blanking, it would produce a standard scanline period and thus artifacts closer to those of standard TV.


Top
 Profile  
 
PostPosted: Fri Oct 30, 2015 1:36 pm 
Offline

Joined: Fri Oct 30, 2015 12:00 pm
Posts: 3
Great. Also just checked, and from FCEUX' PPU viewer it seems like each of "tiles/cells" could use any of the 8 palettes out there, worth 4 colors each.
I THINK I can "purposely" make the sprites to blink here through software (in case a virtual sprite limit is reached), and I THINK I can achieve NTSC distortion by animating the necessary tiles according to the plane/sprite's vertical position and to each pair/unpair "frame number".
Is there any available NES color chart out there?
And finally, what's the maximum sprite size? (leaving alone the obvious possibility of mapping them)


Last edited by GL|Hcktrox on Fri Oct 30, 2015 1:41 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Fri Oct 30, 2015 1:41 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10063
Location: Rio de Janeiro - Brazil
GL|Hcktrox wrote:
And finally, what's the maximum sprite size?

Same as the Master System: sprites are either 8x8 or 8x16, globally (it's not a per-sprite setting).


Top
 Profile  
 
PostPosted: Fri Oct 30, 2015 1:43 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
GL|Hcktrox wrote:
Great. Also just checked, and from FCEUX' PPU viewer it seems like each of "tiles/cells" could use any of the 8 palettes out there, worth 4 colors each.

The background uses only the first four palettes, and the sprites use only the last four. Background palettes are assigned not to 8x8 pixel areas but to 16x16 pixel areas (2 cells by 2 cells).

Quote:
Is there any available NES color chart out there?

Image
Why you won't see Fifty Shades of Grey on the NES


Quote:
And finally, what's the maximum sprite size? (leaving alone the obvious possibility of mapping them)

All single sprites in a scene are 8x8 or 8x16.


Top
 Profile  
 
PostPosted: Fri Oct 30, 2015 1:47 pm 
Offline

Joined: Fri Oct 30, 2015 12:00 pm
Posts: 3
Thank you so much!
I'll update this post once I get a part of this level added and working within game.

tepples wrote:
Why you won't see Fifty Shades of Grey on the NES

XD. This made my day.


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 11:46 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 577
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
tepples wrote:
The Genesis VDP can show 16 sprites and 32 slivers per line in 256 pixel mode or 20 sprites and 40 slivers per line in 320 pixel mode. The NES can show only 8 sprites and 8 slivers. So I'd guess the sprite limits can be simulated by putting six high-priority 32x32 pixel transparent sprites on each line with more than 8 sprites in order to eat up 24 of the 32 slivers, though that would also eat up most of your OAM. (The sprite display list in Genesis 256px mode has only 64 entries, as on the Master System and NES.)


Sprite list has always 128 entries, just that only first 64 (or 80) sprites are parsed before cycles run out on that line (order only determined by the 7bit link value in sprite definition).

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 12:05 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10063
Location: Rio de Janeiro - Brazil
So there are more entries than the VDP can parse per scanline, and you choose which ones will be parsed by creating a linked list? Interesting... I can't see much benefit in having sprite entries that won't be used though...


Top
 Profile  
 
PostPosted: Sun Nov 01, 2015 1:44 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19104
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
I can't see much benefit in having sprite entries that won't be used though

I guess it allows static allocation of display list entries to particular actor slots even if different frames of animation take more or fewer sprites. This frees the CPU from having to rerun the allocation every frame the way it is done on the NES.


Top
 Profile  
 
PostPosted: Mon Nov 02, 2015 2:33 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
TmEE wrote:
Sprite list has always 128 entries, just that only first 64 (or 80) sprites are parsed before cycles run out on that line (order only determined by the 7bit link value in sprite definition).

Er no, only 80 entries, the VDP explicitly cuts the list the moment you try to use entries 80~127 (don't forget that those entries don't have room in the sprite cache). Also apparently it cuts sprites after 63 in H32 mode (though 64~79 are still usable if they were cached before... albeit it wasn't stable if I recall correctly).


Top
 Profile  
 
PostPosted: Mon Nov 02, 2015 4:49 pm 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 577
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
I don't recall link values higher than 79 or 63 cutting out the rendering...

EDIT: Just did a quick test. Sprite at 0 and one at 127, and both display... buuuuut there's a peculiarity. The second sprite doesn't seem to have the Y coord I supplied on the hardware (it is positioned correctly in the emulator), rest is correct though.
EDIT2: Sprites from 80 to 127 seem to fix the Y coord at my first sprites one.
EDIT3: I added a second sprite, aaaaand the sprites in 80 to 127 are totally messed up in vertical direction. I can make out the GFX as it flickers line by line between the two normal sprites. How fun.
EDIT4: Any sprites coming back from 80...127 to the 0...79 range will not be rendered it seems.
So I will have to eat my words. Stay away from 80...127 and stick some GFX into those bytes instead !

http://www.tmeeco.eu/BitShit/SpriteFunTest.jpg

_________________
http://www.tmeeco.eu


Top
 Profile  
 
PostPosted: Tue Nov 03, 2015 6:05 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
OK so in other words the VDP just sees high impedance from the sprite cache and whether something works or not (and how) depends entirely on whatever noise it happened to read. ¯\(º_o)/¯

Well, the warning stands, I guess.


Top
 Profile  
 
PostPosted: Wed Nov 04, 2015 3:06 am 
Offline
User avatar

Joined: Wed Feb 13, 2008 9:10 am
Posts: 577
Location: Estonia, Rapla city (50 and 60Hz compatible :P)
Rather there is something weird going on in the sprite evaluation circuit, the line buffer does store stuff properly, but where exactly the GFX ends up is all barfed.

_________________
http://www.tmeeco.eu


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 14 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group