It is currently Mon Jun 18, 2018 6:52 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
PostPosted: Fri Jun 08, 2018 9:30 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20157
Location: NE Indiana, USA (NTSC)
Using "processor" for sufficiently stateful ASICs was already common by the mid-1980s.

  • Open up your ColecoVision, CreatiVision, or SG-1000 and find a Texas Instruments TMS9918 family picture generator, described in its datasheet as a Video Display Processor.
  • Open up your Sega Master System or MSX2 and find a TI-derived Video Display Processor.
  • Open up your Nintendo Entertainment System and find a TI-inspired Picture Processing Unit.


Top
 Profile  
 
PostPosted: Fri Jun 08, 2018 9:47 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1606
Location: Gothenburg, Sweden
Quote:
Nowadays pretty much every chip is a processor of some kind, but back in the 80s and 90s, that wasn't the case.
Maybe i'm reading you too literally, but i think it's still not the case. Operational amplifiers, logic gates, sensors, shift registers, memory and timers in the form of a separate ic package are everywhere, which naturally don't execute code.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Fri Jun 08, 2018 5:35 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2694
I guess they were always called processors, even though they're not programmable. I still wonder how the general population think old systems work. Somebody should get a bunch of people together and ask them to each draw a diagram of how they think the system works, and it will be interesting to compare and contrast their designs with both the real thing, and each others diagrams. I wonder if there would be brothers who have been talking about technical stuff for years, suddenly realized they understood each other differently this entire time.


Top
 Profile  
 
PostPosted: Fri Jun 08, 2018 7:22 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3387
Location: Mountain View, CA
psycopathicteen wrote:
I still wonder how the general population think old systems work.

Spun off this thread: viewtopic.php?f=5&t=17428


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 3:09 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 447
All computing can be reduced to IPO, its a computer if it does IPO. Input Process Output. So any ASIC/CPLD/FPGA is a processor, as it will take some form of input, "process" it and then form an output. It does not even need a Clock let alone an Instruction set to be a processor. You can make a Processor board from discrete components as well. That is how computers were made before the invention of the IC, and then before and well still after the invention of the Microprocessor. My microwave oven proudly boasts that it is Microprocessor based, and that it is LSI ( yeah not even VLSI ;) )

For me 8-bit graphics relies upon the rough resolutions and in turn amount of items one would see as possible for an 8 bit based computer to process. Its not just well is 320x240 16 colour and then its 8-bit, if it has screen high objects moving around and 25 other things moving then its not running on an 8-bit processor. The graphical limits refer more to "what it can update" rather than what it can "render". I.e Mayhem in Monsterland can be considered to be 16bit graphics, as the graphical fidelity makes you question "are you sure this is not an A600".
So for me, Shovel Night is not 8bit, Bloodmoon also not 8bit. Undertale is 8bit ( I think it even goes as far as having attribute clash ). Rock Bashers yeah 8bit. Aqua Kitty, Scott Pilgrim vs the World 32 bit.

8bit does not need to be 4:3 most home computers of the era are 16:10.

8bit bit pallets formats need a second param to specify the bit depth of the palette. So
8/12 if you have a 256 colour image on an Amiga
8/15 if you are mode 7 on a SNES
8/555 or 8/565 if you are on early PC adapter
8/24 is the "new standard 8 bit palette"

There is a GDC talk where a person talks about 8bit graphics and starts at EGA (/)_. which is 16bit graphics. the comment thread is "fun" ;)


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 6:10 am 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 985
To me, "8-bit graphics" means 256 colours are possible; that is different to what a "8-bit computer" is, which (depending on the computer) may have "4-bit graphics" or whatever, since that is separate.

_________________
.


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 6:18 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20157
Location: NE Indiana, USA (NTSC)
Oziphantom wrote:
Its not just well is 320x240 16 colour and then its 8-bit, if it has screen high objects moving around and 25 other things moving then its not running on an 8-bit processor.

You mean like a Recca boss and the bullets flying around?

Oziphantom wrote:
The graphical limits refer more to "what it can update" rather than what it can "render". I.e Mayhem in Monsterland can be considered to be 16bit graphics, as the graphical fidelity makes you question "are you sure this is not an A600".

Could you cite video timestamps of parts of that C64 game that can't be done practically in, say, a Tiny Toon Adventures game on an NES or Master System? The technique of layering a hires outline sprite over a multicolor sprite is clever, but it's aesthetically roughly the same as the face layering in Mega Man series.

Oziphantom wrote:
8bit does not need to be 4:3 most home computers of the era are 16:10.

That depends on the pixel aspect ratio, and for most of these old platforms, it isn't square because it isn't 6.136 MHz, the rate at which 240p pixels are square. Namco arcade platforms, Nintendo 64, and Neo Geo come closest to that ideal rate. But Commodore 64 pixels are exactly 3/4 of an NTSC scanline wide (hires) or 3/2 (multicolor). This means a plane of 320x200 hires pixels or 160x200 multicolor pixels has the same width as 240 scanlines and thus a display aspect ratio of 6:5.


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 10:11 am 
Offline

Joined: Mon Apr 16, 2007 10:07 am
Posts: 116
tepples wrote:
Could you cite video timestamps of parts of that C64 game that can't be done practically in, say, a Tiny Toon Adventures game on an NES or Master System? The technique of layering a hires outline sprite over a multicolor sprite is clever, but it's aesthetically roughly the same as the face layering in Mega Man series.


This shows 3 C64 sprites in a row (not counting Mayhem's overlay). That's 72 pixels of sprite on the same scanline. The NES and SMS (with unzoomed sprites) can only manage 64 sprite pixels on the same scanline. Am I correct?

Then again, look at Mayhem's statusbar. Half of it lives in the scrolling area of the screen and it's all made of sprites.

Actually, I would be genuinely interested to know if there are any NES/SMS games that manage something like Mayhem's title screen.

_________________
Insert witty sig. here...


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 11:00 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7211
Location: Seattle
Oziphantom wrote:
8/15 if you are mode 7 on a SNES
8/555 or 8/565 if you are on early PC adapter
For very roughly the first five years, most VGA/SVGA cards/clones were runtime-selectable 4/666 or 8/666. The 565 depth was exclusively for the directcolor mode, without a palette involved.
For easier comparison, we should use the same convention for everything. PC Engine was 9/333; SMD was 6/3332. EGA was 4/222, SMS was 5/222; NES was 5/h4s0l2

Oziphantom wrote:
8bit does not need to be 4:3 most home computers of the era are 16:10.
tepples wrote:
That depends on the pixel aspect ratio, and for most of these old platforms, it isn't square because it isn't 6.136 MHz
The IBM 5151 monitor doesn't display a 4:3 picture. Things running on a Hercules card with it don't display at a PAR of 2:3 but instead closer to 3:4 (makes the dials circular in the last version of MS Flight Simulator to support Hercules). Personal measurement shows the active area of the glass is roughly 3:2, which is consistent. (EGA-on-5151 uses a slower dot clock; PAR there is closer to .85)


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 11:12 am 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1606
Location: Gothenburg, Sweden
@Hojo_norem:

It's true that you can't have more than 8 sprites per scanline, but you can make them appear as having a wider coverage circumstantially with strategic placement.
Attachment:
fighter_spriteboxes1.png
fighter_spriteboxes1.png [ 18.58 KiB | Viewed 216 times ]


You could perhaps approach something like the status bar on the scrolling area on the NES if:

a)your cartridge mapping allows for chr banking

b)you know for sure that the background on that row is going to be very limited in its content variance; maybe mostly monocoloured clouds, a dusky sky in a horizontal scroller.

c)make use of the 8 sprites you've got to cover for some of the content. If the information needs to be dynamically updated; better use the sprites mainly for that.

d1)You can then prerender each possible outcome for a limited selection of letters/symbols.

d2)optionally, and if you have chr-ram, upload them to chr-ram as needed so they don't take up too much active tile space.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 2:40 pm 
Offline

Joined: Mon Apr 16, 2007 10:07 am
Posts: 116
FrankenGraphics wrote:
@Hojo_norem:

It's true that you can't have more than 8 sprites per scanline, but you can make them appear as having a wider coverage circumstantially with strategic placement.
Attachment:
fighter_spriteboxes1.png


I agree that you can make larger meta-sprites by spreading out the hard-sprites, but that still does not address the fact that the NES/SMS have a maximum of 64 hard-sprite pixels per line as opposed to the C64's 192 (unexpanded) pixels. I can't see this being worked around practically without flickering on the NES/SMS.

Quote:

You could perhaps approach something like the status bar on the scrolling area on the NES if:

a)your cartridge mapping allows for chr banking

b)you know for sure that the background on that row is going to be very limited in its content variance; maybe mostly monocoloured clouds, a dusky sky in a horizontal scroller.

c)make use of the 8 sprites you've got to cover for some of the content. If the information needs to be dynamically updated; better use the sprites mainly for that.

d1)You can then prerender each possible outcome for a limited selection of letters/symbols.

d2)optionally, and if you have chr-ram, upload them to chr-ram as needed so they don't take up too much active tile space.

Mayhem (and probably many other C64 games) has complex moving GFX behind complex stationary GFX. Again, while I accept that these approaches are possible, I can't imagine that they are practical from a CPU time or hardware cost (probably more CPU than anything, especially on NTSC).

Thing is, if the C64 had the same sprite size limitations as the NES, Mayhem probably wouldn't have scrolling background behind the status bar. I'd just set a raster IRQ to go off just above it and reset X scroll to zero. Seeing that Mayhem uses a VSP type scroller, I may have to store the status area in a different video bank, but that's no real inconvenience.

The stock NES doesn't have a real programmable raster IRQ generator, but the SMS does. I don't know if it can change scroll positions outside of VBLANK though.

Anyways, all of this only addresses the status bar, of which the top half is actually made from X-expanded sprites, meaning there are still enough sprite pixels for Mayhem himself (with overly) and a couple of enemies. Speaking of sprite pixel counts, the NES has a total of 8192 hardware sprite pixels (8x16x64) per frame, not counting the 64 pixel per line limit. The C64 has 4032 (24x21x8), but these can easily multiplexed in software. I've heard some games manage 24 sprites... that's 12096 pixels! Here's some more of them being put to use.

_________________
Insert witty sig. here...


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 3:36 pm 
Offline
Formerly WheelInventor

Joined: Thu Apr 14, 2016 2:55 am
Posts: 1606
Location: Gothenburg, Sweden
Quote:
I can't see this being worked around practically without flickering on the NES/SMS.

Indeed, that's what you have to do. My favourite examples are bubble bobble in general and the long whip in castlevania. These games rely on sprite priority cycling for their design to function interactively at all.

Quote:
I can't imagine that they are practical from a CPU time or hardware cost

I don't think CPU time or presence of IRQ:s have too much to do with it for the mentioned trick to work. If your game pak allows for chr-paging, you're ever only one write oer frame away from animating tiles, which opens up the possibility a broad selection of features. Mass scale tile animation, parallax distortion of the playfield without need for timers, or, to a very limited extent, sprite-like appearances. Cost is not much of a problem these days, either. It perfectly feasible to use 32kB:s of external RAM for graphics, which gives you more than plenty of room for these tricks. The drawback is that you have to design your stage accordingly, ie, ideally make sure that all the letters need access to the same page of scroll-triggered animation. Else you need to dynamically update the contents of the pages, which would take some cpu time. Still, some games do update the chr table continously. Solstice, for example. So it's certainly feasible for *some* game designs.

For clarity, i'm not arguing whether a straight port of Mayhem as-is would be possible (you have to accept drawbacks). I'm just interested in what can be done, homebrew-wise.

If you'd make a new game with a steady title over a scrolling background, you'd need sprites to cover all edges and 8 banks of chr-rom/ram to flip between; each with a scroll-compensated tileset for the logotype itself whereas the rest is identical across all banks. Some clever shadowing using the common background splash colour would make it easier, but it's not necessary. You don't see this in old commercial games because it was a waste of expensive storage, but these days..

The NES PPU not being able to multiplex its sprites is a bit of a drawback, but on the other hand, 64 is quite plenty to keep track of given the available time to update the OAM and the rest each frame. I feel the number of sprites (quite generous at the time) were a conscious design choice in regards to that the old way of doing it (multiplexing) wasn't on the table.

_________________
http://www.frankengraphics.com - personal NES blog


Top
 Profile  
 
PostPosted: Sun Jun 10, 2018 6:10 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20157
Location: NE Indiana, USA (NTSC)
"Jupiter Scope 2: Operation Europa" in one of the Action 53 volumes has a title screen with a large title over a scrolling background, similar to Mayhem. It draws half the sprites in even frames and the other half in odd frames, creating a semitransparent effect. This is effective because the background is mostly dark, and it might not be quite as effective with high-contrast cartoon backgrounds like those of Mayhem.

Now if horizontal sprite coverage without flicker determines what is and isn't 16-bit, Game Boy is 16-bit. It has 50% coverage with just sprites, not even counting what can be done with a "window" background. (See Prehistorik Man.)

The Master System can change horizontal scroll in mid-draw. The NES can change both horizontal and vertical scroll in mid-draw.


Top
 Profile  
 
PostPosted: Mon Jun 11, 2018 12:35 am 
Offline

Joined: Tue Feb 07, 2017 2:03 am
Posts: 447
So
Mayhem in Monsterland has a 320x208 full screen with unique colour per 8x8 char, with 24 enemy sprites + 4 for Mayhem + sprite status screen. It can scroll at 1 char per frame. It can also use colour splits for graphical effect.

https://youtu.be/ldo2ewLBt3Y?t=1912 Note the hires pixels in the circles, note that mayhem is behind some of them. Also note the birds outline is black, but the fish is dark blue, watch as it crosses the water line and switches to black.
https://youtu.be/ldo2ewLBt3Y?t=1865 note how mayhem is between things in front of the pink and (would be purplish mountains on a crt) but behind the green and the trees. Also note how the eyes on some trees follow while others don't. Then watch as he collects the invulnerability pickup and sparkles.
https://youtu.be/ldo2ewLBt3Y?t=1968 hi res parallax scrolling and more water splits
https://youtu.be/ldo2ewLBt3Y?t=2857 Waterfall + that enemy and then there are still more enemies on the same line with mayhem and then at the end he gets invun which he could go back and visit the monster again.
https://youtu.be/ldo2ewLBt3Y?t=571 also sprites

To do this game on a NES or SMS you would have to drop the enemies and mayhem to 16x16 and drop the world to 256x224 which is going to completely change the dynamics of the game. You would also have to rearrange the sprite and enemy placement to avoid flicker.
the graphics is not the only thing that makes you say "is that an Amiga?" because his animation - he has over 50 frames, and the smoothness of his movement and momentum are also quite high for an 8bit machine - they are not perfect, but very high for an 8 bit. There is also 3 tunes per level, and 3 track music with up to 2 sfx played.

For large scrolling "background layer" see
Hawkeye which has a fixed background https://youtu.be/ASoRpGQ6zfo?t=603
Fimbo's Quest which has a scrolling background https://youtu.be/SiCxXMquPKs?t=157


Top
 Profile  
 
PostPosted: Mon Jun 11, 2018 5:57 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20157
Location: NE Indiana, USA (NTSC)
I looked at your Mayhem examples from a "how'm I gonna port this to NES?" point of view.

Oziphantom wrote:
https://youtu.be/ldo2ewLBt3Y?t=1912 Note the hires pixels in the circles, note that mayhem is behind some of them.

Both NES and Master System can do that effect using sprite-to-background priority.

Oziphantom wrote:
Also note the birds outline is black, but the fish is dark blue, watch as it crosses the water line and switches to black.

In that particular scene, there appear to be two enemy palettes from the NES-ist point of view: one for submerged enemies and one for enemies above the water line.

Oziphantom wrote:
https://youtu.be/ldo2ewLBt3Y?t=1865 note how mayhem is between things in front of the pink and (would be purplish mountains on a crt) but behind the green and the trees.

Crouch for five seconds on a white block in Super Mario Bros. to see a similar effect.

Oziphantom wrote:
Also note how the eyes on some trees follow while others don't.

Artistically yes, it's attention to detail, but technically not more difficult than the "some pumpkins are decoys" rule in Haunted: Halloween '85.

Oziphantom wrote:
Then watch as he collects the invulnerability pickup and sparkles.

Or Sonic in 8-bit Sonic the Hedgehog.

Oziphantom wrote:
https://youtu.be/ldo2ewLBt3Y?t=1968 hi res parallax scrolling and more water splits

It's a repeating 16x16 pixel pattern shifted as a second repeating background layer. I've seen that sort of effect in Battletoads, and I've implemented it before. In a CHR ROM game, you'd instead do like MetalStorm, use 4 BG + 2 OBJ switching, and devote one of the 4 background windows to parallax tiles for this effect.

Oziphantom wrote:
https://youtu.be/ldo2ewLBt3Y?t=2857 Waterfall + that enemy and then there are still more enemies on the same line with mayhem and then at the end he gets invun which he could go back and visit the monster again.

Yes, that's a large enemy, and I concede it'd probably the first thing to start flickering.

Oziphantom wrote:
https://youtu.be/ldo2ewLBt3Y?t=571 also sprites

You mean those spinning star-shaped coin things? Compare to the spinning round coin things in the background of Super Mario Bros. 3.

Oziphantom wrote:
To do this game on a NES or SMS you would have to drop the enemies and mayhem to 16x16

Or 16x24 (Balloon Fight size), which would maintain roughly the same size given the pixel aspect ratio difference. A sprite that's 24 C64 pixels wide is 24*3/4 = 18 square pixels wide, and a sprite that's 16 NES pixels wide is 16*8/7 = 18 square pixels wide.

Oziphantom wrote:
the graphics is not the only thing that makes you say "is that an Amiga?" because his animation - he has over 50 frames, and the smoothness of his movement and momentum are also quite high for an 8bit machine - they are not perfect, but very high for an 8 bit.

There are about 50 frames in each player character in The Curse of Possum Hollow as well.

Oziphantom wrote:
For large scrolling "background layer" see
Hawkeye which has a fixed background https://youtu.be/ASoRpGQ6zfo?t=603

But not much color depth, nor much frame rate on the background.

Oziphantom wrote:
Fimbo's Quest which has a scrolling background https://youtu.be/SiCxXMquPKs?t=157

That one's impressive. But again, not much frame rate on the background.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page Previous  1, 2, 3  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 3 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