Thanks, I'll check some of those things out. A goal of mine was to understand how computer graphics were done and then be able to program some 2d graphics and 3d graphics in the 'old' way, either with C or perhaps with assembly for 2d. So I know now how this stuff works in a basic sense and can make some graphics, but mastering the programming methods is a lot of work especially when needing to learn specific hardware. So I definitely have gone all over the place but that's partly because I like both bitmap stuff and polygons so I get inspired when I see one or the other, also there are just so many systems and languages since the early days and then I also thought I should learn some kind of OpenGL/DirectX to do Windows stuff or just because that's the way now with the api's, so I went that way a bit too. But I'm more drawn to the older methods as far as understanding what's happening.
I guess the CEL system is maybe one of the first to do sprites like textured polygons?
OpenGL can be cool although APIs change all the time (now it's considered outdated and people go for Vulkan), but it's still worth to try it. For more understanding of the internals, figuring out how to build things in a software rendering engine will be best.
They do say that Sega perfected the art of hardware zooming sprites in their coin ops before CEL went similar. But it still seems to me they just wanted to figure out how to stretch a bitmap to the screen and this also went with forward texture mapping (reading every pixel of your bitmap then scaling things up to fill the space) instead of the more common and more effecient in general reverse texture mapping (filling a polygon area, figuring out which samples from the bitmap to read back to fill that area). It's strange, maybe in CEL hardware this is more effecient, but doing forward rendering in software the way hardware does is the super non-effecient way to do it. But emulators do it, I've done it in emulating the CEL for my own ports, it still kinda works but way slower than reverse texture mapping.
Hm, that's an interesting comment about the APIs and encouragement to learn software rendering. I did notice OpenGL was on its way out, but I think I went that way because I found freeglut or some such recommended to get a window up to allow drawing of primitives (I didn't realise in the beginning you couldn't interact with the video system directly like on the old hardware), though maybe people use SDL now. That's why I just started doing stuff on the GBA because it has a bitmap mode and I didn't have to worry about the API stuff for now. But also seeing your DOS 3D it made me wonder whether that's a better way. Yeah that's kind of ironic that the APIs keep changing yet they are designed to kind of universalise it all.
To me the super scaler stuff seemed more like scaling and rotation but not distorting in 3d, but I don't know much about the hardware. I thought the Saturn was doing stuff more like the CEL, and possibly copied it. I remember people saying they weren't 'real' polygons but distorted sprites.
I don't know if you're interested in some of the 8bit homebrew but there is some impressive Russian stuff on the Spectrum. There's a guy called Retrosouls who does a special colour engine which allows more colours per 8x8 block. He just released another one, Yazzie Junior, I think. But there's an Alien Breed demake that looks really cool with this colour mode.
Whatever you do is cool to learn though and maybe you can connect the knowledge by trying things. I watched recently some Jonathan Blow video where he said OpenGL is outdated and why do you even need to learn that anymore, but I think it's ok to learn and it is still used at places. Then look at software rendering to connect the dots of how things relate and everything will click together as long as you try things and not worry too much.
I had briefly seen 8bit spectrum stuff and it's cool. I coded for Amstrad CPC 8bit sometimes in z80, I've tried also coding on Speccy it's more simple. I might check the Yazzie Junior, it was on my feed, probably I follow whoever posted it.
Yeah, I think the N64 was using some derivative of OpenGL so I guess if people wanted to program that it would still be useful. I think for the newest 3D stuff I can understand they want the most powerful and so on and will discourage people from investing in it if they want to do the latest games, I guess.
Is the Amstrad screen layout weird like the Spectrum?
That guy is on here, so maybe you already follow him. But his YT channel is this.
https://www.youtube.com/@speccyrook
The Russian/East Europe spectrum scene is pretty hilarious because they just put everything on there they can. There's a cool Abe Odyssey I saw and Doom was on there somehow, maybe with sped-up emulator. But this Denis guy just does originals by the looks of it.
The Amstrad CPC screen layout is similarly weird but different. If you write linearly you still go from line 0 to line 8, 16, etc.. first line of every char. Then after 2048 bytes you reach the end and then starts line 1,9,17,etc... Similar to Spectrum but there that variation is split in 3 sections of the screen. Technically it's easier on CPC given Y coordinate to know where you are. Or to move from line to next line you add 2048 till you reach last line where you have to subtract 2048*7 and then add 80. But on Speccy the only positive, 32 bytes per line, 8*32 = 256 to go to next line in 1/3rd of the screen. So you can increase high byte of register and are in next line, easier and faster than on CPC. Also, the bitmaping of 4/16 colors on CPC is so weird and illogical compared to what you would expect.
I was looking at the Amstrad for a bit, partly because I wanted some midtones and the colours are pretty nice I think, better than the c64. But I learned about the screen memory and it seemed that it could never be as fast as the Spectrum. Though I came across some French guys who were talking about some way to get hardware scroll by exploiting something, they were still waging the war against c64 and Spectrum haha. Speaking of the screen memory, I assume the Spectrum would maybe outperform the early CGA PCs with the early 86's since I think the CGA is 16k or something screen memory, but I wonder if it would even compete with the 286 with bitmap graphics performance. What do you think?
Yes, CPC videoram is slower to move with the CPU, not even because of the memory layout, but it's simple 16k compared to 6k on Speccy (and 8k on C64). Speccy and C64 have tile restrictions to achieve that, like they have 16 colors, but only 2 or 4 colors per 8x8 tile, but CPC has all 16 colors (from a palette of 27) you could put wherever you want, with the disadvantage of big videoram. Hardware scrolling solves this (but not as easy to do it in pixel perfect movement as in the C64). Speccy at the same time, because of so small videoram, you can easilly recreate fast moves/copies of data in the vram using entirely the CPU and still reach 50hz. The fastest clear screen on CPC could reach around 31fps (with clever stack usage to point at end of vram, 10k max at 1VBL) and memcpy even less (can only move 4k at 1VBL) so 12.5fps probably.
CGA was funny to try on my previous DOS game jam, Skellywave. Initially I thought it would be like CPC, still 16k of vram, but I thought there would be double or quad buffering like CPC, but Nope. You just don't have more than one page on hardware unless you set up a blockier 320x100 or some other weird text mode based 80x50 that looks like blocky pixel res. For targetting 8086 that was already very slow to draw things in a backbuffer and copy the whole thing. Maybe I was getting 10-15fps on the old hardware, I don't recall. So, I only renderered and erased the sprites in vram, which normally would produce horrible flicker, but I had a strategy where I sorted sprites from top to bottom, to later erase/draw timed racing faster than the screen refresh so that it never flickers if your CPU sprite rendering/erasing code is faster overall.
About 286? Depends. With a fast ISA gfx card like Tseng Et4000 it's nicer but still bottleneck. 64k of vram with 256 colors, I can get 80-95fps clearing the screen the fastest way, but copying a backbuffer will drop to half, so under 1VBL. Then you can set up mode-x resolution and hardware scroll, I've seen really smooth 2d games running on 286 or 386 this way. Now if you let the 286 or 386 do things in CGA mode on a VGA card, the original memcpy of whole framebuffer is way way faster and I didn't even to do the tricky sorted sprites trick. But I was targetting 8088/8086 so..
I saw a game called Xevious on the CPC the other day, it was really smooth, I was impressed. I'm curious about what the average fps of the Spec games were, I'm assuming around 25 with the very optimised ones getting to 50 maybe depending on the graphics. But then some aren't scrolling per pixel and different parts are at different rates I think so it's hard to get a straight answer. But I saw a conversion 'Nothing' on the spec by some Russian guy that really looks close to a modern indie game in performance, though I guess maybe it's 25fps in reality.
So if available, the double buffer would generally be used to avoid 'racing the beam' to stop flicker? That's one thing I'm concerned about on the 48k spec, if it can't do double buffer and there's all that trouble. I'm not sure if it can't at all, I just read that somewhere.
That is the skeleton in the maze game, right, I saw that and it got me thinking about spectrum versus early DOS because I thought it was running good and I was trying to remember how the games on my family 286 as a kid were, like Alley Cat and so on.