Jump to content

MaicoD

Members
  • Posts

    7
  • Joined

  • Last visited

Everything posted by MaicoD

  1. I too missed out on the 8-bit micro and console era, and all I had was my dad's 386 work PC. When I saw Alley Cat (in all its magenta and cyan CGA glory) for the first time though, I was amazed that this 'boring' PC could also animate sprites! Similarly when I saw 16-color EGA graphics for the first time (in games like Space Quest etc.) I was hooked! Yeah I did the same and hung out at my friend's house with his Amiga 500, and that was a reality check. The Amiga in the late 1980s was just orders of magnitude more impressive than the PC. I went down the C++/DirectX path myself, but like you I'm also interested in the X16. I'm really a "2D" gamer at heart and, while possible, I feel it doesn't really "ring true" to use a fraction of the capabilities of a ridiculously over-powered modern 3D graphics API for designing 2D games. I'd much rather program on an 8-bit or 16-bit platform to accomplish this using bitmaps, as opposed to textures on billboarded polygons.
  2. Oh boy... bad or outdated documentation isn't just the province of spaghetti coders or self-publishing enthusiasts. It is even practiced by a certain IT multinational based in Redmond in the US state of Washington (in other words, "they who must not be named") Currently I'm trying to add video playback functionality to my DirectX game framework so it can support "cut scenes", intros or end game movie sequences. Those familiar with earlier versions of DirectX may remember the DirectShow API which served this purpose, but this was deprecated and superseded by Media Foundation at the start of the 2010s. So there I am referring to the current Media Foundation online docs which refer to compatibility with "Windows Vista, 7 and above". The example introductory tutorial still targets Windows 7, and as already mentioned above, it's a case of "just paste these header and class files into your project and you're good to go". When I added all the Media Foundation code and tried to compile in Visual Studio, I received a flood of linker errors. After frantically googling, I found that there were dependencies on library files which the official docs had neglected to mention! Gaaaa!!! The beginner tutorial also sets up an app to play media from a URL source you submit in a dialogue box, which I also think is weird. Wouldn't most beginners just want to see code to play a locally saved MP4? And how!!! I encountered this phenomenon last year when I made it my mission to buy up secondhand copies of all those 90s game programming books I could never afford back in the 90s. A helluva lot of those books for game programming in DOS and then Windows 9x were written by Andre LaMothe. All the books he actually authored were amazingly thorough. If you believe the back cover blurb, he was also quite the thrill-seeker into a number of "extreme" pursuits... so I always wondered how he could be the same person who could sit down long enough to write so many texts on how to code games in C!!! So as you can imagine from such a personality, his paragraphs were profusely littered with high-five terms like "boo-yah!" and "touchdown!" He was one of the good (and very entertaining) authors... later on however, there were more than a few books which carried his name on the cover but his sole contribution appeared to be a preface or an introduction to a book which was a thinly disguised reference manual. At least I was purchasing these books used... but I'm sure we've all suffered the disappointment of paying good money for a programming text which ends up being mostly padding, personal anecdote and shoddy "example" code (with the absence of any end-goal working game to plug it into, or at worst just doesn't work). I've learned it's a classic case of "buyer beware" and it pays to do your research. Amazon reviews are one of the first places you should consult and some of the feedback is incredibly detailed. It has certainly helped me avoid a few purchases but also made me eager to buy others.
  3. I've been binging Dave's Garage episodes all week after only just discovering his channel. He's a former Microsoft Windows operating system programmer and you'd be amazed at just how many Windows features and quirks he was responsible for. It's not all about Windows though... he's also a darn good storyteller and his content should appeal to just about everyone in the X16 community. Highly recommended!
  4. Absolutely spot on. A solid understanding of matrix math is compulsory and non-negotiable for 3D game development. Another prerequisite is an understanding of the physics of light to perform pixel shader lighting equations. It helps to know a little physics to code collision behaviors in 2D games but it's nothing near the complexity of 3D. In the early 2010s I decided to study Java, and after just a couple of months and with the aid of some Java game textbooks, I had a working game engine. The next week I had developed my first Pong clone, the week after that a Snake clone, and then the week after that I coded a Space Invaders clone. And all this on my work's laptop PC and working full-time! I was on a roll, but then I had to devote my time to learning SQL for my job, and I also felt that the era of developing in Java was over (ok, ok... I know Minecraft is written in Java but that's just a minor outlier) The point being just as you say, that you can measure progress in 2D in terms of minutes and hours, instead of weeks and months! And that's the truth. There just aren't any boundaries on modern hardware. A hobby game developer simply just cannot build a 3D world on their own (I've found out the hard way). That's why I believe it's not just nostalgia driving the groundswell in retro computing... there must be thousands of enthusiasts just like us yearning for 8-bit and even 16-bit hardware so we have real memory and other programming constraints that limit our horizons, but at the same time allow us to pit our skills against the limitations and complete a project within a decent timeframe. Yeah I'm going through the whole cycle of emotions as well when it comes to my own project, a fully functioning DirectX 12 game demo built completely in Visual C++. I admit it's very unusual these days when virtually everyone from hobbyists to game studios use Unity or Unreal, but this explains why I feel a little isolated because I'm not part of a community to keep inspired and motivated by. That's the price you pay for swimming against the stream, but it's the way I've always done it ever since the Borland Turbo C days. Finally I just want to echo your observation that each component of a modern game is itself very much a full-time discipline. That basically implies the days of the lone game designer are numbered... and that's exactly where retro computers can come in to save the day!
  5. Unlike most in the X16 community for whom their first machines were C64s and Amigas, I was introduced to computing on a 386. So instead of experience with 6502-based architectures, I pledged allegiance to the x86 (in other words, the dark side) Nevertheless, during high school in the late 80s I spent most weekends at a friend's house where we played on his Amiga 500. And boy, was I in absolutely no doubt of just how superior my friend's Amiga was to my dad's work PC for games in every way. Then the 90s hit and we all know the trajectories plotted by the fortunes of Microsoft and Commodore. If some suggest that in view of events, it was a happy accident to have started on a PC after all, believe me I take no pleasure in the fact that for the past three decades and counting, Windows remains ubiquitous. In the twilight of MS-DOS I was learning C with the goal of making Sierra style adventure games, but when DOS was removed from Windows beginning with XP, I went off and did other things. With time I returned to coding as a hobby, and did a deep-dive into the modern way of pushing pixels to the screen by learning one of the common graphics APIs behind most games since the late 90s (in my case, DirectX). What's all this got to do with 8-bit computers you ask? Well this is it... while I'm proud of keeping up to date with the way graphics are done today and I can build some interesting Windows demos, it's apparent I'm never going to make a game. Today's versions of the leading graphics APIs are focused on producing near cinematic quality visuals and can achieve near-photo realism at 4K resolutions which is of course what most AAA titles (with huge budgets) desire. But that's also the problem... with such a limitless capability offered by today's GPUs and 64-bit PCs, also comes the limitless potential for paralysis. This is what has happened to me... I can't bear to open up my latest Visual Studio project any more. I'm attracted to retro computing more than ever because at one time all you needed was a C compiler, Paint Deluxe, and a cozy 320x240 screen resolution... and then watch your shareware contributions flow. I'm not sure if the X16 will be right for me, but I really enjoy reading the forums and look forward to the day when coding projects return to being manageable and above all, fun!
  6. Man, those were the days... once you discovered that plotting pixels in any DOS graphics mode was as easy as setting a pointer address to 0xA000:0000 in EGA/VGA memory, then incrementing the pointer to fill the screen pixel array with the colour palette index of your choice... you entered the magical realm of PC graphics where life would never be the same... The next step of the journey would be displaying PCX images and sprites to screen, then Bresenham's line algorithm and eventually polygon rasterization... add a bit of logic and you had your very own DOS game. And if it's possible to feel more nostalgic for a development environment than the actual game you designed with it, then... Borland Turbo C, you were simply the best!
  7. Just adding my thoughts to the discussion about why the Commander X16 is worth the wait. I've spent all year so far working on a DirectX 12 project, with the goal of designing a 3D game for Windows desktop that's neither an FPS nor a flight sim. It's all being developed in Visual Studio/C++/HLSL, ie. not in Unity or any other game studio. My game framework so far successfully implements many features expected of a modern 3D game environment, including bump mapping, dynamic reflections, real-time shadows, a first-person camera, ability to pick geometry by mouse, and collision detection. It also supports post-processing effects such as HDR tonemapping, bloom and depth of field. However, after a recent month-long battle to get skeletal mesh animation working (which was finally solved), the burnout finally set in. What got me through each day of DirectX pain was turning to my favorite YouTube channels, namely 8-Bit Guy, LGR, RMC Cave, and Retro Recipes to name a few (see the pattern here?) Yes, despite being up to my neck fussing with modern PC graphics, I can't wait to wind down on YT with a classic DOS, C64 or Amiga game review, or a show-and-tell with a classic piece of computing hardware from days gone by. So naturally I did see all of David's episodes about the announcement and subsequent progress of the X16, but after sighing wistfully, it was mentally filed away and I thought if only I wasn't committed to modern-day 64-bit game programming for Windows... So there was a lot of internal conflict going on between what I really wanted to do deep down, and what I 'ought' to be doing. My justification for continuing with the current project was along the lines of, well, imagine if kids and developers had access to today's graphics hardware in the 80s? Wouldn't it be a dream come true? It's a reality today, so why not revel in it and take advantage of the latest technology instead of limiting ourselves to 8-bit era computing power? Well take it from me... I've found out the hard way that the latest and greatest GPUs and 3D APIs may be a boon for gamers and AAA game studios, but for the indie developer or hobby programmer it can be an absolute nightmare. Firstly, if you aren't able to cope with matrix math or pixel shader lighting equations then 3D programming isn't for you. Assuming you do grasp the math and physics of lighting, then there are the 3D APIs to wrangle. You absolutely MUST have experience with previous versions of Direct3D or OpenGL if you want to program with the latest generation APIs (DX12/Vulkan). Ok, assuming you have previous 3D experience. Sure, with a few tutorials you'll be able to render a few spinning cubes and even maybe a textured 3D model imported from a tool like Blender. But to populate a reasonably decent game world will take hundreds of hours at the very minimum. Building an animated 3D character and its associated textures and armature rigging alone may take weeks... and of course you'll want more than one game character. Then what about the game world itself, and physics, and AI? The crunch for me came when I realized my 'game' would never progress beyond the engine phase. There are just too many literal moving parts for an individual game designer/programmer to create and manage on one's own. And of course, when developing for Windows there will be change. We're on the cusp of Windows 11 right now, and that likely means an update to DirectX isn't far behind. In other words, be prepared to push that boulder all the way up to the top of the hill again. And then I remembered the X16 project and looked at Matt Heffernan's 65C02 assembly tutorials. Luckily I've got some x86 assembly behind me, so I dived right in and I haven't looked back! It's helped me break out of an unending loop and I'm certain I'll have something to show for it at the end. Programming for the X16/VERA graphics chip emulator has brought back the fun and anticipation that had been drained by trying to go it alone with a Windows game. That's why waiting a little longer for the final product (even in kit form) doesn't bother me. So that's why I'm a convert and I'm sure I'm not alone. As far as I'm concerned the X16 has already achieved its goal to make coding fun again. A bit long but... thanks for reading!
×
×
  • Create New...

Important Information

Please review our Terms of Use