I'm watching your videos because I love "low" level programming languages and game dev. I've tried to get into game dev multiple times with Unity and failed. I think it was because I felt like I was learning Unity too much, and not feeling like I could get much coding done. I saw your first episode of this series, and it 100% made me realize I could just code a game in C++. Huge props for your videos for inspiring me to attempt game dev in C++.
I used to do a bit of amateur game development back in the day (probably more than 15 years ago). I like this kind of content and the way you present it. The thumbnails are quite eye-catching too, possibly the best use of AI I've seen really. Also the shirts are spectacular.
Nice to see your code examples, it may help the viewers if you add in some extra comments to explain what small blocks of code do, you know what the code does but viewers may not find it easy to decipher. I have been programming since I was at school and I'm now 65! My first experience of assembler programming was on a Science of Cambridge Mk 14. It was a small single board computer with a small led display and a hex input keyboard. Programs had to be loaded into memory, by hand, each time you switched it on! You had two work out the assembler you needed on sheets of paper and then allocate the appropriate hex values to match the assembler mnemonics. Then type them in through the hex keyboard and finally run the program. A very small program could take hours to hand assemble and enter. Pure torture! But back in those days very exciting. Your game task is very interesting so I am looking forward to the next installment.
I thought I'd comment to help the algorithm. I love your style (video format not shirt. 😁😁) . I would seriously consider the Usagi Electric format of a few different projects on the go and rotate. Usagi is one of my favourite channels and you're not far behind. 😉
I tried doing something like this when I first learned C and it was overwhelming. Now that I'm experienced enough it's fascinating following along the process. Ignore the Python haters, it's a great language to build data tools with. They are just jealous you are so competent in multiple languages. I'm building my own 2D game in GameMaker Studio and these videos are also a real motivation to sit down and write my own code instead of clicking on the other random stuff suggested on the side of this video.
You asked. I will answer. I'm watching because it is interesting to see the development process, warts and all, it is fascinating to get an insight into it. I used to do a bit of C++ and other programming but nothing to any great end, but if I ever decide to return to doing that, rather than my other projects, this provides (and will provide) inspiration. Thanks for the interesting videos.
I love low level programming. I was working on a megadrive game a while ago. Also, you are very entertaining to watch. Half the time I don't know if you have an amazing dead pan humor or you're just unintentionally funny. Regardless, it's a lot of fun!
I'm watching this kinds of video's to see how other developers work and think. And dreaming of creating a big game one day. But I'm guessing, that that will take another 20 years :)
Thank you for not making "One of those videos" ! And I have to agree, I've been messing with C strings for a while on my current project, it's ... something.
I like the idea of you writing DOS based gaming stuff, and having people shouting at you to fix things..is also engagement!. Also doing stuff on the Raspberry PI, expecially if it's unusual stuff on the Rasberry PI rather than the usual turning on a LED etc. I think I spotted your deliberate mistake in the code. I'll send you my internet driving licence so you can endorse it with my 100 internet points and you can advise me on the monetary fines that have to be paid and what mandated video punishment I need to sit though to atone for my careless observation that allowed me to fall into your trap there ...! ;)
There's another channel called "Memelvar" here on RU-vid, who's making an NES game in assembly, in case you're curious. I also tried programming for the Sega Genesis, and I can totally understand the pain of little documentation for these old machines. I didn't get much farther than some flashing colors on my attempt, lol.
I'm just here for the shits and giggles, learning something new comes second but is certainly part of the experience. Really though, I'm here because its not a typical "gamedev" series and the way you're willing and able to talk to me like I'm there pair programming with you, bouncing ideas off each other and coming up with a solution. Since I can't speak back realtime, I suppose I'm the rubber ducky in this relationship. 🦆🦆
About your flash drive. Does the Agon support network drives for booting or loading an HDD? You should then be able to connect via eth between the two (crossovers are usually not needed anymore these days) if you want to keep it off the main network. You may also have some luck connecting via USB-C if the Agon supports thunderbolt 3 or some other protocol that allows for USB-C negotiation.
Just so you know: The eZ80 does actually execute normal bog standard Z80 code just fine. I have my own eZ80 board here, and have written a complete CP/M 3 BIOS on it, all using the original ZMAC macro assembler running on CP/M. You can treat the eZ80 as just a very fast Z80 from a software perspective, and it works perfectly fine. The only differences are in the bus timings and hardware IO. But even the hardware dependent things can be handled in Z80 assembly using a vintage Z80 assembler. Yes, the eZ80 has some advanced addressing modes and stuff, but you don't have to use them. In fact there are only two places in my code, from the boot ROM to the A:> prompt, that use eZ80 instructions: That is one LDIR in 24 bit mode right at the start, to copy the ROM code to RAM, and the MLT (multiply) instruction in a subroutine.
I watch these videos because I like to pretend I understand what low level programming is. Or programming in general, really. I'd like to see you doing that DOS 3D thing you were talking about. It would give me nostalgia, I think
Have you considered using an integer mask for the direction, so you can support multiple directions simultaneously? This can also reduce the number of CPU instructions for querying, thus saving memory. Additionally, using bit logic might save some additional cycles. Something like this (move_player function): typedef struct Direction { DIR_NONE 0x0 DIR_LEFT 0x1 DIR_RIGHT 0x1 move_amount.x += (dir & DIR_LEFT) + (dir & DIR_RIGHT); player->move_amount.y += (dir & DIR_UP) + (dir & DIR_DOWN); } ...of course, you can also pass in an easing curve. Perhaps sinusoidal or quartic ... Another bonus is that as you update code and add or remove features which touch the mask code, it won't break and you won't introduce a difficult to find bug.... since it is just "ANDing" and "ORing: values. If you don't handle a case, it will still work. If you handle a case for something which was removed, it will still work. I think the only time you'd need to be vigilant is if you replace a mask definition with something totally different... i.e replace DIR_RIGHT = 0x1
I like your tile data type, BTW. It reminds me of Photoshop .atn files. Great that you're using a specified length for the name string, rather than relying on NULL character termination.
I found your videos when i was looking at the rc2014; really liked your presentation style so I stuck around. Have you considered a neo6502 for when you are ready to jump into asm; similar product to the agon but has a real 6502 instead of a ez80 microcontroller larping as a cpu
I apologize if I am writing too many comments. Re: memory. Rather than using malloc and free, how about allocating all free memory as a single thing, and then using bump allocation within that? Removing or resizing blocks can optionally call a coalising function to defragment the memory. This can easily automatically avoid memory errors such as leaks and use of freed mem. Thus as the game becomes more complex, you won't have to think about memory.
I was thinking about doing my own memory allocation, I couldn't decide whether it was a good idea or just an excuse to get lost on a side quest. I still might do it though since it sounds like an interesting problem to solve.
As far as handling errors, such as file loading and parsing... a way to get around quitting is to have no errors. What I mean by that isn't that your code will be perfect and never encounter an unavoidable issue.... but I mean, make zeroed data a valid result for anything which then just takes another path through your code, just like anything else in the program. So, when a file cannot be found, the zero result would result in calling a function to display an error message on the screen.
Coding with hardware limitations is fun! I have a version of asteroids running on an 32x24 LED matrix, Red ONLY and it looks terrible! Terribly fun to code though. Written in python. Also, TILED is a great tool for game dev. I've used it on other projects
@@ncot_tech I think these videos would benefit from having the episode number in the title text (e.g. "#3") so people don't accidentally watch them in the wrong order. Also I think it would be good to have them in a dedicated playlist so we can binge them in an afternoon with a bucket of popcorn :)
I'm watching your video because I'm interested in how you are making this game on a limited system. I'm building my own limited system so this is very interesting for me.
Nice video! I noticed your IDE/font combines characters. Personally I find _!=_ more readable than *≠* Or _->_ instead of *→* But, each his or her own.
No I'm with you on that, the code is actually done in a website that turns code into pretty formatted images, and I noticed it'd done strange things to the characters too. I'll switch the font for the next one, it was annoying me too!
Why do I watch these videos?.... because the vast majority of indy games use or make an entire game engine. Most of these games are so simple, that they would be far better off just writing the game code to do what it needs. Using generic code makes everything more complex. Sure, sometimes it is easier to get up-and-running, quicky, but later on the progress of development will crawl due to complex and state-resulted bug fixing, getting around dependencies not quite doing the right things, and optimization issues. So, I think you're going the right way, whether targeting a Z80 or a Threadripper.
