Graphics rendering on Japanese 8-bit PCs
Graphics rendering on Japanese 8-bit PCs
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.
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.
Re: Graphics rendering on Japanese 8-bit PCs
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:
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:
Flood fills in Videomation are slow for the same reason.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.
Re: Graphics rendering on Japanese 8-bit PCs
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.
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.
Re: Graphics rendering on Japanese 8-bit PCs
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.
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.
Re: Graphics rendering on Japanese 8-bit PCs
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.tokumaru wrote:However, the drawing routines needed to manipulate the display pixel by pixel, something that's fairly slow in systems with tiled displays.
Videomation looks rad.
Re: Graphics rendering on Japanese 8-bit PCs
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.
Re: Graphics rendering on Japanese 8-bit PCs
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.
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.
Re: Graphics rendering on Japanese 8-bit PCs
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.
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.
Re: Graphics rendering on Japanese 8-bit PCs
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).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.
Re: Graphics rendering on Japanese 8-bit PCs
Perhaps I misunderstood what the problem was. It's been a LONG time since I developed for C64
Re: Graphics rendering on Japanese 8-bit PCs
Right. Assuming that you mean the VIC-IIThe memory acesses are interleaved between the CPU and the VIC-20
It looks something like this:
Code: Select all
6510 mem access
__________________
clock |
________________|
VIC-II mem access
Re: Graphics rendering on Japanese 8-bit PCs
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)
Re: Graphics rendering on Japanese 8-bit PCs
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.
- Hamtaro126
- Posts: 818
- Joined: Thu Jan 19, 2006 5:08 pm
Re: Graphics rendering on Japanese 8-bit PCs
Agreed, Q(uick)B(asic) does the same thing. so does any early basic ending around until Visual Basic got released!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.
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.