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 started doing this sort of stuff when I got my first own PC in 2001. My brother provided me with a pirated Turbo Pascal package, and that got me hooked 😃 It was a bit of a surprise when in 2008 he learned that I was still using TP, so he suggested I learn a more modern language like Ruby, which I did. From there I went on with Arduno, Processing, now also doing electroinics, then Python and C# and OpenGL (like 20 years late, but whatever). What ever I did, I kept reinventing the wheel, writing my own units/modules/libraries for loads of readily available things, just to learn about them. Programming computer graphics has taught me more about physics and math than highschool ever could. So, what I mean to say is, I totaly see the appeal of this project, and I enjoy watching you take it on. You're a very pleasant person to watch 🙂
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 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 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'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 :)
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 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.
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'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.
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 UA-cam, 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.
Great to see the game coming along, but sadly I've no Agon light (yet) to follow along with. Looking forward to some x86 / vga assembly stuff that i can play with in Virtual Box :) Thanks for the videos!
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.
This is an amazing effort. Well done. Use the right tool for the right job, I agree with you completely. This is not the project to do in assembler. Adding python in where it makes sense is a perfect choice. Python is well equipped for handling data and XML is data. I love 6502 assembler by the way, was my first language. This is quite the labor of love. Good for you. Don't listen to any naysayers 👍🏼
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
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.
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.
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 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.
SOO you asked why we are here. I have no interest in the Agon; except it's an interesting platform to see you work on. I am here for the C, although I use C# as my go to language. (Didn't even know how to spell Agon.) Although some Pi and other things MIGHT be fun to mess around with personally. I love your style and comments very umm nice explanations a lot of the time. I imagine, and NOT sure I would do it, but I made a Zelda clone on basic, back in the day. Maybe I should revisit that. IF I had the time, money to do it. I always wanted to do a Text based game again. I have a small one in C# core, should revisit that. Then you got to build all the tools to even make a game hehe. I would suggest next time you're doing the Agon hardware. If you could show your debug screen. I imagine it still refreshes weird as it clears the screen each frame. You might put in a second or two of delay to let your eyes adjust while it goes to a low flicker. Some tinkering might get it to a reasonable state. I would be interested in a one-off tutorial, for your basic setup, for python, agon and c setup. Getting a working platform is always the REAL challenge for me. I mean a step-by-step guide. You explained your sprite and tools, but missing some of the connection bits. (AND if you take on a new challenge, seeing a tutorial for that would rock.) SUCH as I have an arcade machine that does blah. I need to take the C to a rom module and install it in the cabinet like this. (As an outrageous example.) Keep up the great work. I am not suggesting PI but would be interested in whatever you had in mind.
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
A great video! Questions I have: - You did notice that your tilemap was slow, but how did you know "Why" it was slow? I find the investigation of such things interesting - You did mention that you're using dimensions as a physics, while it does work, why haven't you for example baked the collisions into convex shapes and just load them with your engine, now I know doing it with the console real-time is slow, but your levels are static, so why not writing a python script for it? it seems way more robust to me as even with bullets and such, these won't be an issue
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!
@@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.
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
QUESTION: can you demonstrate the process of this game’s game design doc, prior to writing code? You do deliver it verbally but I have noticed the most missing piece of almost every tutorial- throughout UA-cam, is showing how to first walk through steps, of writing the program design - the so called rough draft.
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.
"We don't call these problems, we call them design constraints"
That cracked me up.
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 started doing this sort of stuff when I got my first own PC in 2001. My brother provided me with a pirated Turbo Pascal package, and that got me hooked 😃
It was a bit of a surprise when in 2008 he learned that I was still using TP, so he suggested I learn a more modern language like Ruby, which I did. From there I went on with Arduno, Processing, now also doing electroinics, then Python and C# and OpenGL (like 20 years late, but whatever). What ever I did, I kept reinventing the wheel, writing my own units/modules/libraries for loads of readily available things, just to learn about them. Programming computer graphics has taught me more about physics and math than highschool ever could.
So, what I mean to say is, I totaly see the appeal of this project, and I enjoy watching you take it on. You're a very pleasant person to watch 🙂
Don't you dare calling your fashion sense questionable! This shirt is amazing!
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.
I love these types of video. Coding for a limited system and making something interesting happen without the use of an off the shelf game engine.
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.
Love this series, started to follow along myself.
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 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'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 :)
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 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.
Watching because - overall process is interesting, good fun facts here and there, and; oh - I saw something shiny and got distracted.
Inspiring stuff, must get my Agon Light 2 setup again and try some of this stuff. Many Thanks
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'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.
Awesome video, programming is always fun, thanks and good luck)
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 ...! ;)
I like watching for aspirational reasons.
I love your fashion sense sir.
There's another channel called "Memelvar" here on UA-cam, 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.
Nice shirt, bro! Love your tutorials!
Great to see the game coming along, but sadly I've no Agon light (yet) to follow along with. Looking forward to some x86 / vga assembly stuff that i can play with in Virtual Box :) Thanks for the videos!
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.
This is an amazing effort. Well done. Use the right tool for the right job, I agree with you completely. This is not the project to do in assembler. Adding python in where it makes sense is a perfect choice. Python is well equipped for handling data and XML is data. I love 6502 assembler by the way, was my first language.
This is quite the labor of love. Good for you. Don't listen to any naysayers
👍🏼
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
LOVE this idea! 🎉
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 watch these videos, because I’m a nerd who collects old tech, and I want to make it more fun
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.
20:10 I came to watch some C code, stayed for the shirt
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 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.
SOO you asked why we are here. I have no interest in the Agon; except it's an interesting platform to see you work on.
I am here for the C, although I use C# as my go to language. (Didn't even know how to spell Agon.) Although some Pi and other things MIGHT be fun to mess around with personally. I love your style and comments very umm nice explanations a lot of the time.
I imagine, and NOT sure I would do it, but I made a Zelda clone on basic, back in the day. Maybe I should revisit that. IF I had the time, money to do it. I always wanted to do a Text based game again. I have a small one in C# core, should revisit that.
Then you got to build all the tools to even make a game hehe.
I would suggest next time you're doing the Agon hardware. If you could show your debug screen. I imagine it still refreshes weird as it clears the screen each frame. You might put in a second or two of delay to let your eyes adjust while it goes to a low flicker. Some tinkering might get it to a reasonable state.
I would be interested in a one-off tutorial, for your basic setup, for python, agon and c setup. Getting a working platform is always the REAL challenge for me. I mean a step-by-step guide. You explained your sprite and tools, but missing some of the connection bits. (AND if you take on a new challenge, seeing a tutorial for that would rock.)
SUCH as I have an arcade machine that does blah. I need to take the C to a rom module and install it in the cabinet like this. (As an outrageous example.)
Keep up the great work. I am not suggesting PI but would be interested in whatever you had in mind.
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
3:10 System Shock. You are describing System Shock.
You can just check if player is colliding with a wall type tile just before the physics runs and if so disable physics?
Great videos, if you also include bare metal raspberry pi programming I’m watching that too.
A great video!
Questions I have:
- You did notice that your tilemap was slow, but how did you know "Why" it was slow? I find the investigation of such things interesting
- You did mention that you're using dimensions as a physics, while it does work, why haven't you for example baked the collisions into convex shapes and just load them with your engine, now I know doing it with the console real-time is slow, but your levels are static, so why not writing a python script for it? it seems way more robust to me as even with bullets and such, these won't be an issue
I like the z88dk dev kit :)
I hug from Brazil!
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!
Awesome series! But I’m guessing I got in at a later video. Which part is this in the series?
@@Seb00lean this is part 3, if you look in my channel you'll see the other videos 😀
@@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.
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
Just a thought. Make your rooms different sizes.
Low level coding, game programming, fashion influencer, and very funny. What's not to love?
where can i buy your shirt?
@@dziuaftermidnight I think they came from somewhere like Shein.
Youre cool man
QUESTION: can you demonstrate the process of this game’s game design doc, prior to writing code? You do deliver it verbally but I have noticed the most missing piece of almost every tutorial- throughout UA-cam, is showing how to first walk through steps, of writing the program design - the so called rough draft.
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.