8 bit games in a modern world

[Derron]

As I do not want to derail the other threads I think its best to start a new one - for proper discussions ;-)

To create some context: I wrote that smooth scrolling (the way Qube did in his game - so after scaling up to eg. 4x he moved entities by 1 real display pixel instead of 4 pixels per "virtual pixel").

Smooth scrolling is not retro - I explained that in Qube's thread (as the visuals needed to take the "blocky movement" into account - eg. by speed to trick the eyes/brains).

Actually smooth scrolling was the golden crown of 8-bit games that the C64 excelled at on TV screens. You can not recreate that via strict authenticity on modern LCD screens as their pixel density and refresh rates differ so you have to "cheat" a little. There were many silky smooth scrolling C64 games and even today some genius has figured out how to do the Amiga game Pinball Dreams on the Amstrad CPC also with silky smooth scrolling ( youtube for proof ).

Smooth scrolling is not retro

Smooth scrolling was very much possible.  Screens have come on a long way, but you still have to pick your monitor with a 1ms delay to get near the smooth refresh rate of a CRT.  And CRT's enabled the limited colour palettes to give a natural anti aliasing.  Plus the hardware was fixed, so you could optimize for it. On modern hardware trying to emulate old hardware you could very easily do it a disservice.

There was "smooth" scrolling possible on the C64 - which means it overcomes the 8pixel-block-border by some tricks.
For example like here: http://1amstudios.com/2014/12/07/c64-smooth-scrolling/

So the trick leaded to the possibility to move elements by 1 pixel. This means in a 320x200 world you could move from 0,0 to 1,0 (instead of needfully scroll to "+8").


You could trick the eye on a CRT because of the way a CRT works - and refreshes the screen (redirected/guided cathode ray). There was some kind of "after glow" (the position on the screen you had a bright "pixel" drawn will be "bright" for a short amount of time after you already moved ahead). So this allowed for some tricky "anti-alias" or "smoothing" effect. Of course this cannot work for all colors.


Now you could say you could use this effects to your effort - to have - like eg. Qube did - "subpixel positioning". Means you render the game at eg. 1280*800 (320*200 scaled by 4x) and now think you could render entities at 1280,0 then 1279,0 and so on as this is possible because you emulate the "ray delay" or so. Ok let's think you can do that: was a CRT able to display 1280x800 points? Think of PAL, NTSC - and maybe even SECAM resolutions (PAL: 704×576). Means on a 1280x800 you might at least move 2 "real display pixels".



@ color alternations
With TVs you could - as Steve already pointed out - trick with the refreshes and create additional colors by just alternating between 2 of the possible colors. With NTSC you got the advantage of having a better refresh rate (allowing the trick to work "less flickery"). But ... with NTSC you loose on resolution (see above for the "movement").


@ color palette
The C64 palette (and others) were not RGB but YUV based. So the palette provided (by Qube) might differ from what we experience/see on a CRT. Especially if you use these "after glow" effect on a CRT you could use that to have lighter colors in a very small area (1x1 pixel ;-)) - eg a glowing fuse of a rocket.
As the palette was part of the compo rules I just accept it as the given one - just wanted to add this point for a bit of discussion.





Now, what are your thoughts - Did I miss something, am I wrong with something, how do you see things when it comes to do a "retro/8 bit game" - what do you see as "allowed" to modernize and what should be kept the way it is. So "how exact should we mimic" ?


bye
Ron

[iWasAdam]

Smooth scrolling was definitely possible on 8bit systems, but you needed to be very clever to do. But it was possible. Even if it wasn't pixel perfect.

Onto the Color palette. Yep, in general color was limited from (usually) a minimum palette of colours, and yes there were aborations. E.g. your red would be different (slightly) from my red... etc
But again, some systems had a limit of how many colours and quite a wide palette to pick from. Look at the Atari systems and vcs for that.
For a modern retro look you should sick with a limited palette

One thing that does mark a 'good' retro look is the basic render resolution. You can see those big pixels. You might scale the window, etc. But the general resolution is loooow 320x200 is a good one to start with.
The moment you are at 640x480 with 32 colours, the look starts go towards 16bit and not 8bit

Where it starts to get really fuzzy is emulating/pretending to be older systems on modern hardware. First is sound. Your looking at square waves
Plus each system had a sonic feel to it.
The look was usually defined by the palette. AMSTRAD were usually only 4 colours from a garish palette. Commodore was a sort of muted palette, but could look bright if you turned up you tv colour. Sinclair and bbc always had the minimal but saturated look, etc

[Steve Elliott]

I think Adam's covered the basics there.  So if you could get smooth scrolling then (if you were clever) why not have smooth scrolling now?

If this was purely a technical excercise then you could use all sorts of 8-bit shortcomings to gain 'authenticity points', colour clash, flickering, jerky scrolling etc.  But for me certainly, in this day and age it would just look horrible if you added all those flaws.  Pixel graphics in games have a certain charm, especially when used with a simulated lower resolution.  If pixel graphics were drawn at a very high resolution then I would agree that it wouldn't look retro, and in my eyes lose charm.  And also, not using a restricted palette loses that certain look and feel of a retro game.  It falls between two stools.

[Derron]

Smooth scrolling was definitely possible on 8bit systems, but you needed to be very clever to do. But it was possible. Even if it wasn't pixel perfect.

So you are saying I was able to render "crisp" (as crisp as possible on a CRT) rectangles between the RGB-CRT-grid of such a TV screen?
I wonder how this is possible.
As said I totally understand that you achieved (with tricks) to scroll on a pixel basis - which "if calculated" means about 2 of the horizontal PAL pixels (if you calc it in pixels) for each "320x200-console-graphics-mode"-pixel.

What I do not understand is, how you would be able to render at let's say "0.25, 50" of the screen - especially without affecting the surrounding pixels (they "melt").
Exactly this is happening if you render your entities at eg. "9,200" in a "1280x800" resolution containing sprites with a scale of 4,4. It reaches points which I could not target on a PAL or even 320x200 resolution.
And you say that is possible - how (as said: without affecting the surrounding pixels by "blurring/melting together")?

I am sure there are ways (special circumstances) to allow very nifty tricks but this?


Edit:
I think sound is easier to "reproduce" (not 100% accurate emulated) than converting the analogue TV signal into the digital one. Albeit hmm ... there is surely some "CRT effect" shader around which simulates a cathode ray.


@ Steve
Yes, these "retro games" (HD and all that stuff) look pretty cool sometimes. But for the compo this wasn't the target - but to "Create a game which matches closely the look and feel of your chosen 8-BIT computer.". So some games might not feel as if they are coming from an 8bit computer (see mine, looks more like an PC game as the mouse control wasn't the most used one ;-)). Others might lack in other parts. This is why Qube did only enforce one strict rule: the palettes.
This is also why I am not blaming him or others (or me) for not being authentic - it is more of a "noticing" and taking the chance to discuss about it. It is needed as during the compos the forum is pretty silent :-). So it is good to let some stuff pass revue after the compo time.


bye
Ron

[iWasAdam]

One thing to remember is that old hardware was exactly that - Hardware.

You then add hardware support for things like multicolor sprites and screen flipping, and some forms of blitter. so some systems had scrolling 'built in' -  If I remember correctly the commodore had all sorts of 'tricks' baked in hardware.

Also you have to think of the hardware not a screen, but as a single or multiple blocks of memory. So scrolling became not an issue of dealing with the screen, but just dealing with a single row of memory. you can then write all sorts of quick machine code to scroll/rotate memory blocks.

And that is the final piece: Machine code. The only way to really get into games programming was to learn and know machine code - there are no compilers, no c++, no visual studio and no tools - just what you create yourself and know. So there are tons of wierd stuff that (although we can see the results) we have no actual concept of how it was programmed. Machine code does not reverse port into tofays readable c++. each machine has it's own particular way of making it do something fantastic.

If you really want to get technical, then there were always ways to push a sytem to doing stuff it 'normally' couldn't. E.G. Spectrums could actually use 2 colors per every 8 pixel 2 lines. instead of the normal 8x8 pixel grid 2 colors. And the list goes on.

Also think about double buffering. You program a system to use a custom screen buffer where you have complete control over how you access it. you write the game to use this buffer. Each frame you then use another custom bit of code to copy 'your' buffer into the screen buffer (or part of the screen buffer). That way you can do all sorts of tricks with scrolling etc. the main cost is that you need the memory to be able to have 2 buffers, etc, etc.

[iWasAdam]

I think one thing I (personally) would like to address is scan-lines.
They don't exist and never did in playing old systems! You never saw them!
Where you did see them was in photos, as scanlines are drawn ass odd and even, and when you take a photo you see one of the fields showing ghosted.

If you magnified crt screen then your saw dots, or pixels, but never scanlines. And it depended on your tv as well. and it was sort of blurry. anything over 256x200 resolution became difficult to see and read individual pixels.

If you had a crt monitor (virtually no one did at first as they were soo expensive). you saw beautiful crisp pixel in pure color.

[Derron]

But isnt that hardware programming limiting already the "possible resolution" - so eg the time you give the cathode ray to move until you set the next color (so it draws it) - simply said?
This does already limit how many "pixels" you could render (let's just call it pixels)?
A CRT has a grid mask for the red/green/blue dots - you can't go more fine-grained than this. And saying this any "subpixel" rendering would leed to the same effect you see with ClearType etc on a modern computer: color bleed. (which then with retina or later resolutions wont be needed anymore as anti-aliasing is no longer needed).

I am interested in how they achieve that an element moves less than a "pixel" - because this is what I understood both of you (and Qube) are telling me was possible. And if so - didn't it affect surrounding "pixels" or lead to "wide pixels" (or gaps you had to fill with background color) .. ?


bye
Ron

[iWasAdam]

No definitely not. Sub pixel stuff was not supported. But you could set up a custom screen (of a bigger size) and render that into the smaller size which would be sub pixel - if it was programmed that way, but usually it was a small buffer being written into a window of the main display.

Today we don't think in that way. a window has a resolution that is not 'set' and may be different for different machines or systems.

But the moment you think of a fixed block of memory/canvas size, suddenly all sorts of things become possible.

It's sort of like when shaders treated every pixel as a unique location with no reference to surrounding pixels - suddenly a different way of thinking was needed, etc, etc

[Derron]

Yes, I always assumed the canvas to be eg 160x200 or 320x200 and all "pixels" I drew were within the given color palette. And I was only able to render at one of these 320x200 pixels ("grid"). The hardware of these computers had limitations which lead to not all colors being able to get drawn on all every of these 320x200 pixels freely. But with tricks you achieved to circumvent these color limitations. Also you were able to trick the eye (color alternation, color ramps) to see more colors.
Scrolling wasn't that easy as it is nowerdays: without tricks you were not able to scroll a complete screen "pixel by pixel" but eg. - for the C64 you scrolled in 8pixel steps. With tricks you got it down to "pixel by pixel".

So far we all go d'accord?


Let's assume this canvas gets magnified (eg a bigger TV). Movement of the elements on the canvas is still done at a "pixel by pixel" base. If the screen is now having a diagonal of 1m this means the element moves more millimeters than on a 12inch transportable TV. So on a bigger screen it look more "jittering/blockish".
This is what I meant when seeing Qube's implementation: it moves "between" the "canvas pixels" as if the magnified canvas gained some more accessible pixels.

Let me clarify again: There was no requirement to do so in the competition and people might like this kind of smooth movement. I was just saying that this wasn't possible (at least I tried to express that) while others said it was possible (most probably because of misunderstanding of what I wanted to say).

Do we still agree on that thing not being possible - or did I still miss a thought?


bye
Ron

[iWasAdam]

a pixel is a pixel - retro system don't use sub-pixels.
But there are no strict rules for modern interpretation 

[Xerra]

I thought about scrolling early on because I was using it to move the screen down for a road and also wanted one of the old school scrolling text messages on the title screen. When I first did the text I actually made it so it went 8 pixels at a time to simulate character based scrolling because the C64 font was 8*8 pixels in size. I then adjusted it for the ramped up screen size so it would look the same.

I had second thoughts later on, because I was using smooth scrolling in the game, so it made no sense that I wouldn't have done the same elsewhere and recoded it. Ironically it was much easier to make it smooth than it was to simulate a jerky routine. It would be the complete opposite on the original machines. A scrolling message moving just characters could be done in Basic - although it would be slow and jerky - but you'd need to use machine code and interrupts to do it by pixel.

You could also do it on the Vic 20 but not many programmers did. A classic example would be Jeff Minters Matrix where he had a simple text scroller which moved by pixels. I was well impressed when I first saw it because I didn't know it was possible on the machine until then.

[TomToad]

Scrolling wasn't that easy as it is nowerdays: without tricks you were not able to scroll a complete screen "pixel by pixel" but eg. - for the C64 you scrolled in 8pixel steps. With tricks you got it down to "pixel by pixel".

Not entirely true.  The C64 had a built in "scroll register" which would offset the screen up to 8 pixels.  You would offset the screen one pixel at a time, until you scrolled a total of 8 pixels, then you would move everything by 1 character (8 pixels) and reset the scroll register back to 0.

Here is an example program straight from the "Commodore 64 Programmer's Reference Guide."

Code Select Expand

10 POKE 53265,PEEK(53265) AND 247:REM GO INTO 24 ROW MODE
20 PRINT CHR$(147):REM CLEAR THE SCREEN
30 FOR X=1TO24:PRINTCHR$(17);:NEXT:REM MOVE CURSOR TO BOTTOM OF SCREEN
40 POKE53265,(PEEK(53265)AND248)+7:PRINT:REM POSITION FOR 1ST SCROLL
50 PRINT"     HELLO";
60 FORP=6TO0STEP-1
70 POKE53265,(PEEK(53265)AND248)+P
80 FORX=1TO50:NEXT:REM DELAY LOOP
90 NEXT:GOTO40