Hey, cool graphics. I stumbled across your YT channel and have been watching a bit. I'm curious how you learned to do software-rendered 3D, I'm guessing you're a professional programmer though, so maybe it's different to someone coming at it as a hobbyist. It feels like a wild goose chase, the resources are just all over the place and unfinished tuts everywhere etc. Anyway, it's interesting seeing the performance you can get on the 386/486 without acceleration, I've been curious how many flat-shaded polys could be pushed on those computers to make a smooth game. I felt like the framerates were often really poor back then but perhaps they were just going for too many polys because your game is looking sharp.
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.
Hey, thanks, that's interesting to hear you learned like that, and is good motivation to keep chipping away myself. I've collected some books and a bit of old source code and whatnot, it more that yeah it's all over the place, different systems, languages, 'pseudo-code' etc, I was drawing some lines and triangles in a GBA emulator just to get a 'raw' system without the modern gpu stuff. Most of the learning material around is directed towards the modern api's and so on. I wonder how they learned software 3d back in the 80's/90's, I guess it was through universities or amongst teams, not sure.
I took a break from the 3d and have been studying some sprite stuff for Spectrum and Amiga. I think I found your channel because I was wondering about the 3d0 2d ability and I read something about it having a blitter based on the amiga/atari concept but it seems quite obscure with the cel thing.
That gamepark, I guess it's similar capability to the N-Gage, maybe similar ARM chip.
Maybe you know this guy, but he is porting this 3d platformer to many retro systems including the 3d0, might be of interest to you. https://www.youtube.com/@noahthepoohloudies8752
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 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.
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.