So it's been a long time! I've been both very busy and pretty lazy. Here's a run down of my current situation.
DOSJUN is still alive, but in a different form: while I plan to release the full scenario eventually, for now I'm going to concentrate on releasing a smaller and more focused game which will run in the same engine. Hopefully this will help highlight any problems before they become huge issues. Some work has already been done on the content and mechanics for this smaller dungeon.
I'm working on a fairly small platformer that will run in the browser. It's certainly a big change from DOS's limitations! I expect that project might release early next year. It would be nice to finish something :)
I'm very recent news, I've been writing a FORTH implementation designed to run on the Z80 chip. This is just for my own curiosity, though I have access to a real Timex Sinclair 2068 and it would be neat to see it in action. I'm almost at the point where users can type in real programs (like the built in BASIC interpreter mode) but not quite. Once it does that, I'll put it on GitHub and everyone (nobody) can shout at me for writing terrible assembly.
I also just realised it could run on the Gameboy with some modifications, like not having keyboard input. Huh.
I've been spending a fair bit of time on the Xbox this year because I set myself a score challenge. I'm also going to America again in a few weeks so I want to get even more ahead so there's no crunch time later in the year.
I've been semi-regularly streaming all kinds of things on my Twitch channel.
I finally finished my League of Legends placements for this season and got put in Bronze 2. I haven't played any Ranked since.
That's about it. Sorry for being quiet for so long!
Showing posts with label DOSJUN. Show all posts
Showing posts with label DOSJUN. Show all posts
Thursday, 20 June 2019
Wednesday, 11 April 2018
Tiny 2018 Update
Haha, I've been quiet for almost 2 months!
I'm in America right now, but I've still been ploughing on with DOSJUN. I've added music support for a certain tracker format, wrote new graphics loading code to hopefully avoid some of those horrible "out of memory" errors and done a lot of planning for the setting and denizens.
I realise that there's still plenty of work to be done. However, it is slightly further away from "I want to make a game" than it was. The scope is starting to creep a little, but I'm still fairly confident that I can release a playable version of the game this year. I'm thinking that I'll come back and add more content later, because J and I have come up with some excellent ideas to make the game deeper.
I'm in America right now, but I've still been ploughing on with DOSJUN. I've added music support for a certain tracker format, wrote new graphics loading code to hopefully avoid some of those horrible "out of memory" errors and done a lot of planning for the setting and denizens.
I realise that there's still plenty of work to be done. However, it is slightly further away from "I want to make a game" than it was. The scope is starting to creep a little, but I'm still fairly confident that I can release a playable version of the game this year. I'm thinking that I'll come back and add more content later, because J and I have come up with some excellent ideas to make the game deeper.
Friday, 26 January 2018
BEWARE... I LIVE
DOSJUN is alive and well. Here's a quick look at the current progress.
Technically, there's a lot going on in the background to deal with this short list.
It is my eventual goal to not only release this game when finished, but also annotate the code well enough that people can actually learn from it.
Progress has been slow for a variety of reasons: I play a lot of games (mostly long ones), I don't always want to program after doing it for hours at my day job, I watch people stream gameplay quite a bit. These things have been true for years, but I want to commit to this project a little harder than before.
I will release the game this year. At the very least, I can release a version then add more content later if the story remains unfinished. There will be at least 5 hours of work every week on it. Making the engine easy to extend has been important to me since the beginning; an example post-release task would be removing the hard-coded character creation and using scripting instead.
I'm also thinking about streaming the programming work. This might seem odd, but I recently caught someone using Rust to write a roguelike and enjoyed the experience, so there must be like minds out there. It should be a novelty for many current devs to see C and DOS!
 |
| You can walk around |
 |
| You can load and save (in safe spots) |
 |
| There are scripted events |
 |
| You can fight random encounters |
Technically, there's a lot going on in the background to deal with this short list.
 |
| A first person view that uses slices of textures |
 |
| A scripting language (and compiler) |
 |
| A dungeon editor (items and monsters too!) |
It is my eventual goal to not only release this game when finished, but also annotate the code well enough that people can actually learn from it.
Progress has been slow for a variety of reasons: I play a lot of games (mostly long ones), I don't always want to program after doing it for hours at my day job, I watch people stream gameplay quite a bit. These things have been true for years, but I want to commit to this project a little harder than before.
I will release the game this year. At the very least, I can release a version then add more content later if the story remains unfinished. There will be at least 5 hours of work every week on it. Making the engine easy to extend has been important to me since the beginning; an example post-release task would be removing the hard-coded character creation and using scripting instead.
I'm also thinking about streaming the programming work. This might seem odd, but I recently caught someone using Rust to write a roguelike and enjoyed the experience, so there must be like minds out there. It should be a novelty for many current devs to see C and DOS!
Sunday, 11 June 2017
Teach Yourself Game Programming in 21 Days - Day 8
This is the chapter I've been waiting for.
I'd messed around with coding and writing games before (on an ancient Casio handheld, among other things) but this chapter made me seriously reconsider everything I'd written until then. It's called "Warp Speed, Anyone?" and it's all about optimising code; optimising for speed, that is. A game can be utterly beautiful, but if it isn't responsive, then it's probably not going to be very good.
The first thing the author mentions is compiler optimisation. Essentially, a compiler is free to reorganise or eliminate code that it deems is in the wrong place or unnecessary. Generally the compiler lets you control how much it tries to 'help' you, which is good, because sometimes it can make the wrong assumptions and make it virtually impossible to track down bugs. Knowing how to write code is one thing; being able to debug the resulting assembly language is another. I've done this a few times in my life, so it's a skill I have (kind of) but I will point out that it's often not the best use of your time. Accordingly, André recommends leaving compiler optimisation settings low, despite the potential speed increase. Games have some of the most complicated code out there; you want it to work, first.
The next major subject is that of the memory model. This will be completely alien to anybody who hasn't worked with DOS before. Early on in IBM's history, the decision was made to separate code (executable memory) from data (read-only memory) by the use of segments. This prevents code from overwriting itself. This is a good idea. However, as the PCs of the time had very little memory, each of these segments was only 64KiB large. This was a bad idea, but nobody knew just how much storage was going to expand in the years to come.
All of the programs I've written so far have fit into the Tiny memory model; only one segment required for both code and data. For a little future-proofing, I've been compiling with Compact (one code, many data) but the author actually recommends Medium (many code, one data)! The reason given is that having only one data segment means it's easier to write inline assembly, because DS always has the same value. If more than 64K of memory is needed (and it will be), it will have to be allocated from the FAR heap, which slows down data access slightly. This might be how DOSJUN ends up; it has a lot of code already. I'll have to write 'far' next to more of my pointers.
The next part makes me sad. The Plot_Pixel_Fast function a large part of the book code has been using is an important candidate for improvement; every use involves a function call and pushing of three parameters, which seems like slight overkill considering all it's doing is setting one byte. My solution to this would be to declare the function as a macro, but the author chooses instead to declare the function's parameters as globals, then add a new Plot_Pixel_Global function which uses these globals. André was probably going for maximum compatibility here, but I can't help but note he missed a trick.
Next come standard techniques - aliasing structures or pointers to temporary variables so they don't have to be repeatedly dereferenced (compilers probably do this automatically) and unrolling loops to reduce the time spent incrementing a counter and jumping. There's also a mention of marking certain important variables as 'register' to ask the compiler to optimise them differently.
Then, lookup tables. This is an easy measure to implement in future programs. It's just a matter of trading memory for execution time. This was already done in Chapter 5 to store the results of sin and cos calculations, but it could be done for a lot more... I'm thinking of using the technique for DOSJUN's graphics.
The largest treatment is given to the technique of fixed-point numbers. The gist is to use integers to store non-integral amounts by keeping some of the bits for the fractional part. This allows us to use the efficient integer addition operations instead of the slower floating point calculations that are offloaded to the co-processor. This is the largest code listing in the chapter, and it has been dutifully typed out here.
The chapter finishes with a fairly lengthy and snarky look at DOS extenders, a sad but necessary evil in the transition period between real mode and protected mode processing. This enabled 32-bit programs on the otherwise 16-bit DOS. I'm not sure if I'll need this for DOSJUN, but I hope not, because it's something I've never done. I think it would be quite bizarre to write a DOS program that required 4GB of RAM. Also, I'd have to find a free online one, or write my own.
Despite the dearth of code, this was a difficult chapter to get through as it is quite dense and there's no pictures for me to take! The next chapter is about playing sounds, which would be great if I could get it to work.
I'd messed around with coding and writing games before (on an ancient Casio handheld, among other things) but this chapter made me seriously reconsider everything I'd written until then. It's called "Warp Speed, Anyone?" and it's all about optimising code; optimising for speed, that is. A game can be utterly beautiful, but if it isn't responsive, then it's probably not going to be very good.
The first thing the author mentions is compiler optimisation. Essentially, a compiler is free to reorganise or eliminate code that it deems is in the wrong place or unnecessary. Generally the compiler lets you control how much it tries to 'help' you, which is good, because sometimes it can make the wrong assumptions and make it virtually impossible to track down bugs. Knowing how to write code is one thing; being able to debug the resulting assembly language is another. I've done this a few times in my life, so it's a skill I have (kind of) but I will point out that it's often not the best use of your time. Accordingly, André recommends leaving compiler optimisation settings low, despite the potential speed increase. Games have some of the most complicated code out there; you want it to work, first.
The next major subject is that of the memory model. This will be completely alien to anybody who hasn't worked with DOS before. Early on in IBM's history, the decision was made to separate code (executable memory) from data (read-only memory) by the use of segments. This prevents code from overwriting itself. This is a good idea. However, as the PCs of the time had very little memory, each of these segments was only 64KiB large. This was a bad idea, but nobody knew just how much storage was going to expand in the years to come.
All of the programs I've written so far have fit into the Tiny memory model; only one segment required for both code and data. For a little future-proofing, I've been compiling with Compact (one code, many data) but the author actually recommends Medium (many code, one data)! The reason given is that having only one data segment means it's easier to write inline assembly, because DS always has the same value. If more than 64K of memory is needed (and it will be), it will have to be allocated from the FAR heap, which slows down data access slightly. This might be how DOSJUN ends up; it has a lot of code already. I'll have to write 'far' next to more of my pointers.
The next part makes me sad. The Plot_Pixel_Fast function a large part of the book code has been using is an important candidate for improvement; every use involves a function call and pushing of three parameters, which seems like slight overkill considering all it's doing is setting one byte. My solution to this would be to declare the function as a macro, but the author chooses instead to declare the function's parameters as globals, then add a new Plot_Pixel_Global function which uses these globals. André was probably going for maximum compatibility here, but I can't help but note he missed a trick.
Next come standard techniques - aliasing structures or pointers to temporary variables so they don't have to be repeatedly dereferenced (compilers probably do this automatically) and unrolling loops to reduce the time spent incrementing a counter and jumping. There's also a mention of marking certain important variables as 'register' to ask the compiler to optimise them differently.
Then, lookup tables. This is an easy measure to implement in future programs. It's just a matter of trading memory for execution time. This was already done in Chapter 5 to store the results of sin and cos calculations, but it could be done for a lot more... I'm thinking of using the technique for DOSJUN's graphics.
The largest treatment is given to the technique of fixed-point numbers. The gist is to use integers to store non-integral amounts by keeping some of the bits for the fractional part. This allows us to use the efficient integer addition operations instead of the slower floating point calculations that are offloaded to the co-processor. This is the largest code listing in the chapter, and it has been dutifully typed out here.
The chapter finishes with a fairly lengthy and snarky look at DOS extenders, a sad but necessary evil in the transition period between real mode and protected mode processing. This enabled 32-bit programs on the otherwise 16-bit DOS. I'm not sure if I'll need this for DOSJUN, but I hope not, because it's something I've never done. I think it would be quite bizarre to write a DOS program that required 4GB of RAM. Also, I'd have to find a free online one, or write my own.
Despite the dearth of code, this was a difficult chapter to get through as it is quite dense and there's no pictures for me to take! The next chapter is about playing sounds, which would be great if I could get it to work.
Sunday, 28 May 2017
Introducing... DOSJUN
It would be remiss of me to merely type out a few words while reading through a programming book from over 20 years ago. Actually developing a video game using what I (re)learn would make a lot more sense. To that end...
It's been a dream of mine for ages to create a dungeon crawler. It's also a lot of work; I've lost count of the number of times I've started making a game only to abandon it or find some other project to throw myself into. Hopefully, this time can be different.
While I haven't settled on any mechanics yet (other than having 6 party members and there being health and mana, apparently) there is a bit of work done on the graphics engine. I'm also attempting to lay my code out in vaguely sensible ways. Feel free to follow along as I attempt to finally finish something.
It's been a dream of mine for ages to create a dungeon crawler. It's also a lot of work; I've lost count of the number of times I've started making a game only to abandon it or find some other project to throw myself into. Hopefully, this time can be different.
While I haven't settled on any mechanics yet (other than having 6 party members and there being health and mana, apparently) there is a bit of work done on the graphics engine. I'm also attempting to lay my code out in vaguely sensible ways. Feel free to follow along as I attempt to finally finish something.
Subscribe to:
Posts (Atom)