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..
Optimus6128
Creator of
Recent community posts
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.
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.
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.
I forgot to answer how did people learn in the 80s/90s. That was the magic of being highly motivated and like to explore the unknown. When I started I wasn't even thinking "How the hell am I supposed to learn if there are no resources?". I just gradually started playing with graphics rendering in 2D and later 3D, and develop a mind of seeing something visual that others did in games/demos and wondering how could I recreate it. It was never a worry to me that some resources are hidden behind university paper paywalls or something (although some folks who happened to study computer science at the time and also did things in games/demoscene, they learned some useful stuff on universities, things you can now find on the internet)
But I remembered another video "HandmadeCon 2016 - History of Software Texture Mapping in Games" where veterans from the game industry were discussing when texture mapping was new and there wasn't a very standard method known (or maybe they didn't always had access to some good resources from university), even those veterans and in commercial games we know (Ultimate Underworld), their implementation of texture mapping was very experimental and would be crap implementation from today's view. They really have to also guess, but if you were motivated and started having this visual mathematics way of thinking, like you see something visual and you start thinking with what algorithms/maths I could recreate it, then it was possible at the time. But it was experimental. They weren't waiting for an answer of the standard way to do this. They thought "I have a bitmap and I need to stretch/fit it in a rectangular area". Yeah, thinking just like 3DO did. They weren't thinking in triangles, because a lot of the games had walls and it was more natural to think of how to stretch bitmap to wall quad, than split into triangles and do it how we do it today.
The CEL on 3DO is not working the same as the blitter in the Amiga. Although it still "blits" bitmap scanlines horizontally and then moves up vertically in any direction and scale, like it uses two vectors and one more to fit a bitmap to any quad area on the screen, so it's doing texture mapping in a sense, drawing textured polygon quads. But if you manipulate the vectors, you can do weird things like curved polygons, very thin one pixel polygons to make line rendering, etc. But at the end of the day, if you write a 3D engine on CPU and you transform/project points to the screen, now you can create the 3 vectors from the 4 quad points and have it fill the quad area with interpolated texture without you having to do that part in software rendering. Makes things possible on 3DO that you would need a 486 or maybe Pentium to do at the same speed. And it's very simple if you understand how it works.
I've seen the guy's work on his channel, he also posted on our 3DO discord once.
p.s. Something else I thought. I said I did something on 1999, then on 2006 I had a first 3d object engine (with gouraud, texture map, fake envmap like in the demoscene) and it seemed like a miracle to me. But at the time I was a bit slow, jumping from project to project, also doing 2d demoscene effects, also doing 8bit assembly on Amstrad CPC, studying for univesity, trying to find a job, etc.. so progress was slower but it was ok with me. But now I realize, if you focus enough you can do a simple 3d engine like in few months. If you see Tsoding's video "One formula that demystifes 3D graphics" you see that a toy 3D engine that does all the mystical things is much simpler than one would think. Of course for extra things (visibility culling, polygons, etc) there is a bigger road head which I took with Bizarro Untergrund. But those are gradually solved if one focuses on the same project and not leave it dormant and jump to other things. All my previous examples were a 3d object rotating in the center of the screen but if you zoom too close it would get nearZ and crash. But enough for a simple demoscene demo :)
I did start as hobbyist but it's like a 20 years old hobby or something. Later I also got a professional job but most of the things I learned on my own, reading the random things here and there, familiarizing myself with the concepts, discussing ideas with the community and so on. I just was highly motivated but also took me a long time to come here (my first true polygon engine was back in 2006 something showing more complex 3d objects on gamepark handhelds with much faster ARM at over 100mhz, but when I look at this old code I would change and improve a lot, it was experimental while I was learning. Long time before in 1999 that I did simple 3d dots rotating and projecting in quickbasic by reading other docs but also visually understanding some of the math, but a lot of the concepts of a full 3d engine were scary).
But you are right there are not enough resources or there are various but hard to suggest one specific. Sometimes I can't find things easily myself and have to do a lot of searching for some old lost resource. Even in this and my previous entry, first time I used PC speaker, I was having issues with interrupts, keyboard, I didn't solved in older stuff (as I was making more demoscene demos and never seriously looked at proper keyboard handling for example).
p.s.I don't know how many polygons are possible but it depends on the size and whether they are textured, shaded or not. In early 32bit systems, few hundreds might be ok, depends. I haven't counted them here. Low poly games with few hundreds on screen would be ok on 486.
I am also late. Idea is wild. I usually am very impatient and don't want to work on something for even 4 years and not release. But I am interested, I have one of the ideas in my mind I want to work with. Some big complete game in quickbasic 4.5 for DOS with an old abandoned engine. Hehe.. and maybe 4 years is ok from now. I wouldn't stand 10 years and not releasing but 4 years ok. Also I will be 50 years old when it ends.
Thanks!
So far I was targeting my Pocket8086 at 10mhz where even in the later stages with 8 enemies max it still keeps at 70fps. But I've tried it on a 8088 motherboard at 4.77mhz and know it will struggle after 3-4 sprites. I was planning to rewrite the sprite rendering in x86 assembly compiled sprites in the hopes of catching up the speed there but jam ended and had no time than. I am still thinking I want to try this and will release a next version here if I get the motivation to try this.
The sprite rendering is optimized enough for C (having pre-generated 4 pixel shifted versions of sprites, bliting 16bits at once and 8bit at the sides, not using mask (black background), not using framebuffer but sorting top to bottom to avoid flickering (rarely it will happen on top)) but I know the assembly rewrite can be even better, just needs some work and new code generators from my side. Your post motivates me to go back to it and try that too. Thanks!
Nice simple idea, interesting platform I've never heard before, I had only issues with not very fast responding controls, like I had to hold the key well to move, couldn't make some fast moves back and forth in the second level with the spiders, so they touched me easily before I could sneak and get the keys.
Interesting platform for an entry. I kinda get how you play, I managed to copy paste the code and run and things were scrolling. Then with the arrows I could move a thing as it was printing text. It's very close down to the bottom of the screen, so you can't see if you crash in time (I guess when I hit certain characters I do crash). Isn't very intuitive to play to be honest.
I like dungeon crawlers. This one is nice, everytime player is random with different stats and different starting items, so it made me replay many times. It's hard to survive, sometimes I get one strong hit and die, others I progress a bit but don't know if there is an ending. I find interesting the use of AI for graphics, they certainly look pretty atmospheric.
Impressive entry for an impressive platform!
I only had a little trouble setting the mouse controls, editing the cfg to invert mouse and reduce sensitivity somehow didn't work for me. So I got a bit motion sick before getting to far with it. It does however seem to be a nice simple game and easy to move around and shoot things.
Wow, cool!
Besides the GCW0, I also have the RG350 from Anbernic so I'll try it myself and see if it works correctly.
UPDATE: Just tried. RG350 displays the colors wrong. I see now maybe the SDL port on RG350 does not convert correctly from 8bpp palletized to 16bit? I could try on dingoonity forum and ask the devs (not sure if it's an issue of opendingux or the rogue firmware I used on my RG350).
Even more funny, it does actually work nicely on GameKiddy 350h. GKD can run OPKs from GCW0/RG350 but is less compatible than both of this (other emuls just fail sometimes), I wasn't even initially expecting to run it there, but I guess their SDL implementation was more correct.
I quite like the clever use of this engine for a driving game, the dark atmosphere and the humor of this game (I think I got Duke as a customer at some point :). At first I lost, but when I played again and got used to the control, it's pretty fun to drive and rush to get the next customer, the map and the waypoint helps.
This is the most technically impressive entry in the compo and a lot of effort has gone to have some kind of story/gameplay and complete levels. I haven't finished seen much of the game yet (still on 1st level, I'll try again with the new patch) but what I've seen so far is pretty decent (need to get used to the controls a bit).