It is currently Mon Oct 23, 2017 3:01 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 14 posts ] 
Author Message
PostPosted: Fri Nov 02, 2012 2:03 pm 
Offline
User avatar

Joined: Tue Feb 13, 2007 9:02 pm
Posts: 147
Location: Richmond, VA
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.


Top
 Profile  
 
PostPosted: Fri Nov 02, 2012 2:15 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19116
Location: NE Indiana, USA (NTSC)
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.


Top
 Profile  
 
PostPosted: Fri Nov 02, 2012 3:15 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10067
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Fri Nov 02, 2012 4:36 pm 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 939
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.


Top
 Profile  
 
PostPosted: Sat Nov 03, 2012 10:51 am 
Offline
User avatar

Joined: Tue Feb 13, 2007 9:02 pm
Posts: 147
Location: Richmond, VA
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.


Top
 Profile  
 
PostPosted: Sat Nov 03, 2012 11:05 am 
Offline
Formerly 65024U

Joined: Sat Mar 27, 2010 12:57 pm
Posts: 2257
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.


Top
 Profile  
 
PostPosted: Sat Nov 03, 2012 11:06 am 
Offline

Joined: Sat Jan 23, 2010 11:41 pm
Posts: 1161
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.


Top
 Profile  
 
PostPosted: Sat Nov 03, 2012 5:03 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10067
Location: Rio de Janeiro - Brazil
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.


Top
 Profile  
 
PostPosted: Sun Nov 04, 2012 3:07 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7235
Location: Chexbres, VD, Switzerland
Quote:
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).


Top
 Profile  
 
PostPosted: Mon Nov 05, 2012 9:22 am 
Offline
User avatar

Joined: Wed Oct 15, 2008 11:50 am
Posts: 939
Perhaps I misunderstood what the problem was. It's been a LONG time since I developed for C64 :D


Top
 Profile  
 
PostPosted: Mon Nov 05, 2012 11:36 am 
Offline

Joined: Thu Oct 05, 2006 6:29 am
Posts: 911
Quote:
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:
                            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.


Top
 Profile  
 
PostPosted: Sat Nov 10, 2012 4:01 pm 
Offline

Joined: Thu Mar 02, 2006 12:30 pm
Posts: 168
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)

_________________
Read my blog! The Incoherent Ramblings of a Lowly Geek


Top
 Profile  
 
PostPosted: Mon Nov 12, 2012 9:40 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
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.


Top
 Profile  
 
PostPosted: Tue Nov 13, 2012 10:48 pm 
Offline
User avatar

Joined: Thu Jan 19, 2006 5:08 pm
Posts: 744
Location: Shelton, Washington.
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.


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 1 guest


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