Graphics rendering on Japanese 8-bit PCs

Discussion of development of software for any "obsolete" computer or video game system. See the WSdev wiki and ObscureDev wiki for more information on certain platforms.
Post Reply
User avatar
noattack
Posts: 147
Joined: Tue Feb 13, 2007 9:02 pm
Location: Richmond, VA

Graphics rendering on Japanese 8-bit PCs

Post by noattack »

I've been looking around for information on various Famicom games that were ported from earlier PC titles, specifically those made by Enix (Door Door, Portopia, etc.). Finding decent technical info (in English) on Japanese PCs is tough, but I have a question that likely applies to several Z80-based processors from that era.

In this YouTube clip (skip to around 2:45) of Portopia on the NEC PC-6001/6601, graphics are drawn in a kind of 'vector-style' -- individual lines and shapes first, then color fills. It's remarkably slow compared to the NES. What is this rendering mode called? And what is the technical explanation for this technique? The Japanese wikipedia article on the PC-8801 appears to have a paragraph explaining the slow drawing mode, but the English translation is too poor to figure out what's going on.

Any info is appreciated. I don't know much about early PC capabilities.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Graphics rendering on Japanese 8-bit PCs

Post by tepples »

I just call it "line drawing and flood fills". Some Apple II graphical adventure games did the same thing.

As for why it's so slow, I think programs had to wait for blanking time to modify VRAM. At least that's the gist I get from the following translated paragraph:
Google Translate wrote:For hardware specifications, such as the processing of the main CPU will suspend operation DMA cycle drawing of the text display (in the PC-8800 series is classified as old models to later), and graphics operating speed models of the above two Although slow and drawn, there was also "fast mode" is written to ignore the timing display to disable the display of the text screen, in real-time game that requires a response by the show, did not benefit from it.
Flood fills in Videomation are slow for the same reason.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Graphics rendering on Japanese 8-bit PCs

Post by tokumaru »

This kind of rendering is not specific to Japanese PCs, it was commonly used in old adventure games because a full screen image could be stored in very little space. Just a few LINE and PAINT commands were enough to draw something meaningful. However, the drawing routines needed to manipulate the display pixel by pixel, something that's fairly slow in systems with tiled displays. First they have to calculate the position of the tile where the pixel is, then read the byte where the pixel is, modify it and write it back.

Of course there are techniques to speed things up, but it will still seem slow in these old computers/consoles. Tepples mentioned Videomation for the NES, but even Art Alive on the Genesis/MD is pretty slow when drawing things pixel by pixel.
User avatar
qbradq
Posts: 972
Joined: Wed Oct 15, 2008 11:50 am

Re: Graphics rendering on Japanese 8-bit PCs

Post by qbradq »

It's not clear from the blurb Tepples posted if this model PC allowed "dirty writes" to VRAM like the Commodore 64 did. On the C64 you could write to VRAM at any time, but doing so during the frame would produce snow on the display (or even incorrect tiles) because the CPU always won the bus conflict over the video unit. Meaning if the video generator was trying to figure out what color a pixel needed to be, but the CPU was accessing the VRAM bus at the same time, it'd see whatever was on the CPU data bus rather than what the ROM / RAM was trying to assert on the bus.

This may be the "Fast" and "Slow" modes being referenced.

Then again it does say something about disabling the display, which sounds more like forced blanking on the NES.
User avatar
noattack
Posts: 147
Joined: Tue Feb 13, 2007 9:02 pm
Location: Richmond, VA

Re: Graphics rendering on Japanese 8-bit PCs

Post by noattack »

tokumaru wrote:However, the drawing routines needed to manipulate the display pixel by pixel, something that's fairly slow in systems with tiled displays.
So are most PCs of this era tile-based? I assumed each pixel was 'independent' since each could be filled with one of eight colors. And if they're tiled, how do they handle object movement without sprites? And I assume scrolling is limited or impossible? Maybe these are dumb questions, but I'm stuck in the NES PPU mentality, so I can't wrap my head around an alternative method of graphics rendering.

Videomation looks rad.
3gengames
Formerly 65024U
Posts: 2284
Joined: Sat Mar 27, 2010 12:57 pm

Re: Graphics rendering on Japanese 8-bit PCs

Post by 3gengames »

They're bit mapped screen. It's just a huge buffer of X bytes, and then 1/2/4/8 bits make up one pixel across the whole screen. Want to move an object? You have to remove the object from the screen, replace the background, and then place the object at another place on the screen. Any more than a few objects and you'll be spanning stuff over multiple frames all the time.
Shiru
Posts: 1161
Joined: Sat Jan 23, 2010 11:41 pm

Re: Graphics rendering on Japanese 8-bit PCs

Post by Shiru »

Some of them were tile-based, i.e. had a text mode with font in RAM. Sprites in these cases were moving by characters. Those that weren't tile-based had non-linear layout anyway, often bitpacked. This makes primitive drawing not very effective.

ZX Spectrum video memory layout is one bright example: the screen consist three parts 256x64 pixels that are placed in the memory one by another (2048 bytes/third, 6144 bytes screen without color); each third has 32 bytes of the top scanline of the top characters row, then 32 bytes of the top scanline of the second characters row, after all rows the second scanline goes etc. This is how it looks if the video memory is filled byte by byte.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Re: Graphics rendering on Japanese 8-bit PCs

Post by tokumaru »

Another example of a popular computer without hardware sprites is the Amstrad CPC. A common solution used by games to implement free moving sprites was to use a low resolution screen mode with 16 colors, but instead of making use of all 16 colors they used 2 bits for the background and 2 for the sprites, so it was easy to manipulate them independently. The games looked pretty bad though (look at Ghouls 'n Ghosts, for example).

But many other CPC games had sprites and scrolling without giving up on the number of colors, it was just harder to program, and involved a lot of bit masking.
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Re: Graphics rendering on Japanese 8-bit PCs

Post by Bregalad »

On the C64 you could write to VRAM at any time, but doing so during the frame would produce snow on the display (or even incorrect tiles) because the CPU always won the bus conflict over the video unit.
Sorry but I don't think a bus conflict can happen on the C64. I don't know where you got this, but it's probably wrong. The memory acesses are interleaved between the CPU and the VIC-20. Which is why unfortunately the CPU is slow as hell (only ~1MHz).
User avatar
qbradq
Posts: 972
Joined: Wed Oct 15, 2008 11:50 am

Re: Graphics rendering on Japanese 8-bit PCs

Post by qbradq »

Perhaps I misunderstood what the problem was. It's been a LONG time since I developed for C64 :D
mic_
Posts: 922
Joined: Thu Oct 05, 2006 6:29 am

Re: Graphics rendering on Japanese 8-bit PCs

Post by mic_ »

The memory acesses are interleaved between the CPU and the VIC-20
Right. Assuming that you mean the VIC-II ;)

It looks something like this:

Code: Select all

                            6510 mem access
                          __________________
 clock                    |
          ________________|
          VIC-II mem access
Depending on the graphics mode, the VIC-II might need to fetch more data than it's able to do with the above scheme (for extra color data, sprite data, ...). In those situations it can take control of the bus by pulling the address enable control pin low(?), thereby preventing the 6510 from driving the address bus for as long as the VIC-II needs it.
LocalH
Posts: 186
Joined: Thu Mar 02, 2006 12:30 pm

Re: Graphics rendering on Japanese 8-bit PCs

Post by LocalH »

Not sure if it was a bus conflict or not, but on the 85xx VIC-II chips (including the VIC-IIe in the C128) a gray dot would appear on-screen when writing to $D020 or $D021 (and I would assume $D022 and $D023 as well, if the CPU is in a region of the screen where those registers are being displayed, such as with multicolor or extended background character modes)
Sik
Posts: 1589
Joined: Thu Aug 12, 2010 3:43 am

Re: Graphics rendering on Japanese 8-bit PCs

Post by Sik »

Looking at that video in the first post, I wouldn't be surprised if that game is made in BASIC, which is not really optimized for speed performance (I'd expect many additional checks and such, as well as bothering more to make the code smaller rather than faster). So in addition to whatever else was said here you need to factor in that.
User avatar
Hamtaro126
Posts: 818
Joined: Thu Jan 19, 2006 5:08 pm

Re: Graphics rendering on Japanese 8-bit PCs

Post by Hamtaro126 »

Sik wrote:Looking at that video in the first post, I wouldn't be surprised if that game is made in BASIC, which is not really optimized for speed performance (I'd expect many additional checks and such, as well as bothering more to make the code smaller rather than faster). So in addition to whatever else was said here you need to factor in that.
Agreed, Q(uick)B(asic) does the same thing. so does any early basic ending around until Visual Basic got released!

If anything, the Earlier versions of the Basic languages is just a ''proving grounds'' for programmers to start, it tests how much they handle thier knowlage of program creation of any sort, back then it's just not suited for LONG or BIG Applications!

People still create VERY short games for Basic, it's a Hobby. :)
AKA SmilyMZX/AtariHacker.
Post Reply