Support NeoGAF

[Damaniel]

Interesting. Got any links so a beginner can start looking into this?

It mainly depends on how deep you want to jump into the rabbit hole.

For the absolute DOS beginner who just wants to put some pixels on the screen, you could just use something like QBasic running in DOSBox. There is a surprisingly active QBasic development community out there even today, with sites like Pete's QBASIC Site and qbasic.net hosting the most information. You can get pixels on the screen with just a couple lines of code, though speed will leave something to be desired.

The way I originally got started with DOS development, back in the day, was in C, using DJGPP and the Allegro graphics library. The first game I ever completed (a mode 13h Tetris clone, way back in 1997) was done this way. Both are still available (the latest versions of Allegro no longer support DOS as far as I know, though downloads of the 3.x and 4.x versions of the library are also available from the site). If I wasn't in experimentation mode right now and just wanted to make a DOS game, this is how I'd go about doing it.

My current interest centers around some of the lesser-documented modes on older video cards like the CGA. Jason Knight (the author of Paku Paku, a Pac-Man clone that runs on really old DOS hardware) has done a lot of work to make the little-used 160x100, 16 color text 'graphics' mode available on even newer hardware, and I've been using that as the basis for some experimentation, and as an excuse to relearn Turbo Pascal and to brush up on x86 assembly language. All completely useless from a 'marketable skill' standpoint, but I find it fun so who cares?

(I don't really want to derail this thread any more, and I hardly consider myself an expert on all things retrocomputing based, but perhaps a DOS-oriented retrocomputing/development thread might be an interesting thing to do someday. For now, I'm glad to have an excuse to put my Dreamcast to work again. )

 

[DoktorEvil]

Subbed!

I want to do this, at least attempt to failure/success.

 

[Krejlooc]

It mainly depends on how deep you want to jump into the rabbit hole.

For the absolute DOS beginner who just wants to put some pixels on the screen, you could just use something like QBasic running in DOSBox. There is a surprisingly active QBasic development community out there even today, with sites like Pete's QBASIC Site and qbasic.net hosting the most information. You can get pixels on the screen with just a couple lines of code, though speed will leave something to be desired.

The way I originally got started with DOS development, back in the day, was in C, using DJGPP and the Allegro graphics library. The first game I ever completed (a mode 13h Tetris clone, way back in 1997) was done this way. Both are still available (the latest versions of Allegro no longer support DOS as far as I know, though downloads of the 3.x and 4.x versions of the library are also available from the site). If I wasn't in experimentation mode right now and just wanted to make a DOS game, this is how I'd go about doing it.

My current interest centers around some of the lesser-documented modes on older video cards like the CGA. Jason Knight (the author of Paku Paku, a Pac-Man clone that runs on really old DOS hardware) has done a lot of work to make the little-used 160x100, 16 color text 'graphics' mode available on even newer hardware, and I've been using that as the basis for some experimentation, and as an excuse to relearn Turbo Pascal and to brush up on x86 assembly language. All completely useless from a 'marketable skill' standpoint, but I find it fun so who cares?

(I don't really want to derail this thread any more, and I hardly consider myself an expert on all things retrocomputing based, but perhaps a DOS-oriented retrocomputing/development thread might be an interesting thing to do someday. For now, I'm glad to have an excuse to put my Dreamcast to work again. )

Ah allegro, I remember people trying to pull me away from SDL with allegro around the early 2000's. I would say, if you're looking to just get pixels on the screen in DOS, that SDL is the easiest way to do that outside of stuff like QBasic. Plus, unlike allegro these days, SDL is still relevant and it extends into OpenGL so well.

The early days of DOS were so funny as there were sooooo many different proprietary graphics libraries out there. "Graphics" in general was such a huge complex world when I first got into programming. I'm really glad I was introduced to SDL so early and had a mentor who taught me how to use it hands-on.

EDIT: As for the text graphics mode in CGA, wasn't that subject to color clash? 8x8 color grids 1-bit color depth, right?

 

[Slayer-33]

I will be in here for moral support

 

[khaaan]

Oh cool, I might even

Step 1: Download and install cygwin

Nevermind.



Cygwin actually isn't all that bad, I just remember being in school and accidentally clicking yes to something my anti-virus said and after that I could not get Cygwin to work no matter what I uninstalled/re-installed. I'll just install a linux environment.

 

[MikeDip]

What a great start. Looking forward to following this, good luck!

 

[Krejlooc]

Thanks for making this, I had no idea the console was so well understood with a dev culture surrounding it. I would get a real kick out of seeing something I made-- no matter how crude-- boot up on a real Dreamcast, so I'll keep my eye on this thread.

You would probably be surprised at the homebrew scenes for retro consoles in general, but the dreamcast is a very special case. Its homebrew scene thrived and was most vibrant when the system was alive. The dreamcast is one of the most celebrated homebrew consoles of all time, and the sort of things people have done for homebrew development of the dreamcast is extraordinary. I chose the dreamcast as the platform for this project because it's development scene the most mature of virtually any home console. I also dabble in Sega Genesis programming (m68k), and PC Engine Programming (using HuC), and I've worked with the Atari Jaguar as well (again, m68k).

The Atari Jaguar has a shockingly vibrant homebrew scene, as people have, since it's launch, successfully come to grips with the hardware and how to use it (and, in the process, realized the machine is actually, no joke, really powerful).

 

[Emperor Bohe]

Thus is wardrobe

 

[hydragonwarrior]

SUBSCRIBEDEDEDDDE

Really, going to read this in full when i'mhome from work

 

[DoktorEvil]

You would probably be surprised at the homebrew scenes for retro consoles in general, but the dreamcast is a very special case. Its homebrew scene thrived and was most vibrant when the system was alive. The dreamcast is one of the most celebrated homebrew consoles of all time, and the sort of things people have done for homebrew development of the dreamcast is extraordinary. I chose the dreamcast as the platform for this project because it's development scene the most mature of virtually any home console. I also dabble in Sega Genesis programming (m68k), and PC Engine Programming (using HuC), and I've worked with the Atari Jaguar as well (again, m68k).

The Atari Jaguar has a shockingly vibrant homebrew scene, as people have, since it's launch, successfully come to grips with the hardware and how to use it (and, in the process, realized the machine is actually, no joke, really powerful).

Interesting.

So why did it fail? The market? The price? The documentation for development?

 

[Krejlooc]

Interesting.

So why did it fail? The market? The price? The documentation for development?

I've been writing an article for racketboy all about the jaguar for months now.

In short: yes, lol. All of the above.

To keep it extra short: the jaguar basically shipped without any documentation what-so-ever, and was handed to a bunch of fresh-out-of-college (and sometimes fresh-out-of-highschool) developers who were told things like "Make a graphically intensive game in 4 months."

The jaguar basically died within a year and a half. It's ridiculous how short the dev cycle for its games were, and many of the games released were the only efforts from developers. There are typically waves of console developement - first wave, second wave, etc. Your first project is a first wave game, your second project is a second wave game, etc. Typically, first wave games are really rough, then second wave games are where developers get grips on the system, and third wave+ games are usually the choice, quality games for a system.

Very few devs got beyond first wave jaguar games before it was killed. Tons and tons of second wave games were killed in development. An extremely small list of devs were lucky enough to produce third wave games, and they are, in general, pretty impressive. Rebellion is one of such devs:

Checkered Flag (first wave) -> Alien vs Predator (Second Wave) -> Skyhammer (third wave)

compare:

https://www.youtube.com/watch?v=E2ox5aAL87c

https://www.youtube.com/watch?v=_kLG8v3O_UE

https://www.youtube.com/watch?v=v0iV5dmIHbM

 

[Arc Christelle]

love you Krejlooc

 

[MrCunningham]

I already have all the dependencies set up under Linux Mint 17, but I haven't set up the toolchain yet. I will get around to that later when I have the time. But so far it looks pretty straight forward on Linux.

Awesome thread though, I will definitely follow it and try to keep up with the tutorial.

 

[Krejlooc]

I already have all the dependencies set up under Linux Mint 17, but I haven't set up the toolchain yet. I will get around to that later when I have the time. But so far it looks pretty straight forward on Linux.

Awesome thread though, I will definitely follow it and try to keep up with the tutorial.

It really is. I spent most of the opening explaining how to use cygwin and what make and makefiles are and all that stuff, because I assumed any linux developer would already know this stuff.

Lession 1, in essence, was mainly about setting up a unix development station within windows. The rest is just downloading and configuring the toolchain. The next tutorial, the one I'll write tonight, is more involved and explains how to actually build your "project."

(project in quotes because there is no single project file).

 

[Tiu Neo]

Subbed, looks really cool, and will probably be a good learning experience. I'll probably build a VM just for that.

Now I just need to get a Dreamcast. They are so damn expensive here.

 

[Big Chungus]

time to pull it out of storage

 

[Mr. RPG]

Really love this idea. Thanks for this. I can't wait to see more!

 

[Damaniel]

Ah allegro, I remember people trying to pull me away from SDL with allegro around the early 2000's. I would say, if you're looking to just get pixels on the screen in DOS, that SDL is the easiest way to do that outside of stuff like QBasic. Plus, unlike allegro these days, SDL is still relevant and it extends into OpenGL so well.

The early days of DOS were so funny as there were sooooo many different proprietary graphics libraries out there. "Graphics" in general was such a huge complex world when I first got into programming. I'm really glad I was introduced to SDL so early and had a mentor who taught me how to use it hands-on.

EDIT: As for the text graphics mode in CGA, wasn't that subject to color clash? 8x8 color grids 1-bit color depth, right?

Color clash isn't an issue, since each 'pixel' is just the top two lines of a text character, and the left and right half of each character (making up the two individual 'pixels') are defined by the foreground and background attribute color. In fact, the mode uses so little memory that even the lowly CGA can support multiple 'graphics' pages in this mode - no need for individual pixels to share attribute bytes. The mode is heavily subject to CGA snow issues on genuine IBM CGA cards (like all text mode stuff), but unless you're running on an IBM 5150/5160, that generally won't be a big issue.

And yes, there were certainly a lot of options for getting graphics on the screen in DOS back in the mid-90s. Allegro was my library of choice back in the day, though plenty of people still just rolled their own pixel plotting and blitting routines in VGA mode 13h and went with those. SDL is a more reasonable modern choice (since it's more relevant to modern OSes and video cards), though I have no experience with using it outside of Windows/Linux.

 

[Krejlooc]

Color clash isn't an issue, since each 'pixel' is just the top two lines of a text character, and the left and right half of each character (making up the two individual 'pixels') are defined by the foreground and background attribute color. In fact, the mode uses so little memory that even the lowly CGA can support multiple 'graphics' pages in this mode - no need for individual pixels to share attribute bytes. The mode is heavily subject to CGA snow issues on genuine IBM CGA cards (like all text mode stuff), but unless you're running on an IBM 5150/5160, that generally won't be a big issue.

And yes, there were certainly a lot of options for getting graphics on the screen in DOS back in the mid-90s. Allegro was my library of choice back in the day, though plenty of people still just rolled their own pixel plotting and blitting routines in VGA mode 13h and went with those. SDL is a more reasonable modern choice (since it's more relevant to modern OSes and video cards), though I have no experience with using it outside of Windows/Linux.

That sounds unlike any other semigraphics mode ive worked with, interesting. Does that mean, in this cga semigraphics mode, you could have a text character of more than 2 colors?

 

[Mr. RPG]

With this series of tutorials, you'll easily be able to make a "hello world!" on Dreamcast right?

 

[Krejlooc]

With this series of tutorials, you'll easily be able to make a "hello world!" on Dreamcast right?

Lol oh ya. In our next tutorial we'll be building an example hello world project, then we'll move on to displaying a png to the screen.

 

[SomedayTheFire]

Great topic, would love to have a go but I lack a Dreamcast!

 

[Laevateinn]

This is awesome. I got into homebrew Genesis development a while back but found it was a little bit too limiting for my tastes and got too bogged down with real work. It's great that Dreamcast tools are now available. With this and GDEMU, I can see a lot of potential for hobby projects.

 

[Relix]

This is amazing. Subbed. I want to join in.

 

[Damaniel]

That sounds unlike any other semigraphics mode ive worked with, interesting. Does that mean, in this cga semigraphics mode, you could have a text character of more than 2 colors?

No, you're still limited to the CGA text mode's 16 color palette. Each pair of pixels is made up of ASCII character 0xDD or 0xDE (these characters are the two 'vertical bar' ones, with the left or right half of the character being foreground color and the other half being background). Instead of showing the standard 80x25 characters on the screen, you increase the display to 100 lines of characters and only display the top two rows of each line (by adjusting some of the CGA registers), creating an effective 160x100 'graphics' mode out of purely text characters. All the graphics operations need to be aware of whether they're starting (and ending) on odd or even pixel offsets, since drawing a single pixel on the screen involves changing the foreground or background attribute for the associated character (exactly which depends on odd or even pixel offset, and on which ASCII character - 0xDD or 0xDE - was used as the base character for pixels).

It's an interesting mode that was only used in a very small handful of early DOS-era games (since 160x100 is rather chunky, and EGA came along to provide higher resolution 16 color modes soon enough). However, the fact that it was possible was enough to get me interested in looking, and fortunately Paku Paku exists to serve as a base for getting started in that mode (though the complete lack of documentation of the source leaves a little to be desired...)

 

[Mengy]

Excellent OP, subscribed. I actually toyed around with making some basic programs for the DC a few years ago, but I wasn't skilled enough a coder to get anything more than a cheap Zork knockoff running, lol. You seem to have a far better knowledge of the DC than I do.

This should be very interesting!

 

[GayForMaster]

Subbed. I have a dreamcast lying, may as well try it since I'm amazing at C.

 

[Laevateinn]

So, I ran into an issue that's unique to Linux. Chances are everyone who would be interested in this that uses Linux would know how to fix this but for the sake of documenting it I think you should add this.

make fails due to lack of permissions to create the directory

/opt/toolchains

so I would recommend that either the user create it themselves with

sudo mkdir /opt/toolchains

and give themselves permission

sudo chown username /opt/toolchains

or to create the folder in their home directory and symlink it to opt

From the dc directory:

mkdir toolchains && sudo ln -s toolchains /opt/toolchains

 

[Krejlooc]

So, I ran into an issue that's unique to Linux. Chances are everyone who would be interested in this that uses Linux would know how to fix this but for the sake of documenting it I think you should add this.

make fails due to lack of permissions to create the directory

/opt/toolchains

so I would recommend that either the user create it themselves with

sudo mkdir /opt/toolchains

and give themselves permission

sudo chown username /opt/toolchains

or to create the folder in their home directory and symlink it to opt

From the dc directory:

mkdir toolchains && sudo ln -s toolchains /opt/toolchains

Ha, my notes I was working on included sudo before every command, actually. I removed them because I assumed any linux dev would know they need super user privileges.

 

[Lemon King]

Really neat idea for a project Krejlooc, going to watch this thread.

 

[Krejlooc]

So im home now, building my toolchaim from scratch again (I'll post oics of the process).

Question for mods - in my next lesson, am I allowed to link to stuff like nulldc?

 

[Laevateinn]

Ha, my notes I was working on included sudo before every command, actually. I removed them because I assumed any linux dev would know they need super user privileges.

It's probably a bad idea to do everything as sudo but that's definitely a workaround

 

[Seik]

That's a really, really good idea!

I have absolutely zero background in development though, so I could be hype/moral support! Or bring a few ideas here and there.

 

[Krejlooc]

It's probably a bad idea to do everything as sudo but that's definitely a workaround

well, not do everything as sudo, lol.

I still trusted linux devs to be able to figure it out. If they couldn't, there was always cygwin lol.

 

[krizzx]

I'm onboard so long as this is a polygon based game, not a 2D game.

You should probably add some kind of copyright clause to this so people won't steal your code.

 

[Krejlooc]

I'm onboard so long as this is a polygon based game, not a 2D game.

You should probably add some kind of copyright clause to this so people won't steal your code.

this is 2D, and I'm writing a public tutorial, so I'm clearly not concerned with people stealing my code.

 

[MrCunningham]

It really is. I spent most of the opening explaining how to use cygwin and what make and makefiles are and all that stuff, because I assumed any linux developer would already know this stuff.

I actually just ran into a little snag while building under linux....

Right here, the bolded part:

./unpack.sh --no-deps

~text~

Execute make with the following command:

make

this will run the makefile that your unpack command generated. This will run for a while, at which point you now have your libraries configured. Go up to the kos folder like so:

If you try to run MAKE during this step in linux, you will come up with a few build errors. From what I can figure out it will work fine in Cygwin, but if you are building in Linux you may have to run this make command as ROOT (sudo su or run sudo make), because the makefile in "/home/user/dc/kos/utils/dc-chain" is targeting to:

sh_prefix  := /opt/toolchains/dc/$(sh_target)
arm_prefix := /opt/toolchains/dc/$(arm_target)

Which requires root access to get to /opt. Or if you don't want to deal with compiling things as root (which can be a bit annoying), you can open up the makefile in your favourite text editor and just change the /opt directories to $HOME/dc.

Hopefully I'm making sense But I think this should be pointed out.


[EDIT] whoops, somebody already covered this. Actually, anyone having this problem under Linux should just follow Laevateinn's directions by making a syslink or just using sudo chown.

 

[perorist]

Thanks for this thread, updating my Linux VM and will try to get started tonight/tomorrow.

 

[Spaced Harrier]

Recently bought a surface pro 3.

Past of the justification was the idea of learning some basic programming. Probably python.
This thread is very interesting to me. If I never post again, you'll know I was too lazy to join in.

 

[MrCunningham]

Alright, toolchain built, and everything's compiled. I didn't get any errors so it looks good. Ready for step two!

 

[Hypemaster]

Thanks OP, you're the best!

 

[krizzx]

this is 2D, and I'm writing a public tutorial, so I'm clearly not concerned with people stealing my code.

Aww. I was kind hoping to finally get to work on a 3D game.

 

[nikos]

I can supply sound and/or music if GAF ends up collectively developing a game. I've always wanted to learn to code, but I don't think my body is ready yet.

 

[Krejlooc]

Alright, toolchain built, and everything's compiled. I didn't get any errors so it looks good. Ready for step two!

That's good to know I successfully laid out the steps to building the toolchain from memory, it's still building on my end. I have the toolchain built on another PC, but I want a freshly built tool chain on this new PC I'm working on to ensure everything works exactly the same as anybody following this topic.

My side of the chain is still building, so the next tutorial is still coming after it's done building. Great to hear it built for you, though.

 

[Exuro]

Just finished building on Ubuntu. Had some permission errors but figured them out. No errors to be seen, so we'll see if it actually worked when the next part is posted. ;p.

 

[Krejlooc]

I can supply sound and/or music if GAF ends up collectively developing a game. I've always wanted to learn to code, but I don't think my body is ready yet.

Feel free to contribute, please. I'm going to supply some art I did for a breakout clone I did back in 2004, but this is sort of like a class project where everyone following along should end up with their own version of the game.

the goal of this topic is to mainly get people's feet wet in dreamcast development, give them insight into how a small game is made, and to give them a jumping off point for experimentation and exploration going forward.

Breakout is such a small game that, realistically, any single person can bang out a breakout clone in a few hours if they know what they're doing. Once people make breakout, they'll have a perfect environment setup so that, if they wish, they can begin making dreamcast games on their own, and will have the knowledge of not only how to set up a toolchain for dreamcast development, but will know how to compile source codes.

These skills translate, btw. The stuff being explained in this topic can be extrapolated to other, non-dreamcast projects. Once you go through the process of setting up a toolchain to compile like this, you gain a better understanding of what IDEs and compilers do in general, and should you ever run across another hobbled together dev kit, you won't be completely lost.

But back to your original point - if anybody wants to contribute anything - art, music, sound effects, etc - feel free. This isn't supposed to be a big game or anything, it's all about learning. If you do create some art, you might want to explain how you did it. One thing to understand, however - the dreamcast has tight memory restrictions. This isn't a PS4. So art assets need to be mindful of this, and we also need to store them in logical ways.

 

[Damaniel]

So, I followed the instructions as described. Either I missed a step or a step is missing from the guide - the initial install steps assume that you've cloned the git repo into a subdirectory of your home directory, but later steps assume the toolchain lives in /usr/local/dc.

EDIT: Sneaky. I see you fixed the instructions. Never mind. I have it working as the instructions describe now.

 

[c0de]

Are we going to have a project site on Github? I want to participate in coding

 

[PetriP-TNT]

Cool! Crossposted this topic to the Programming OT

http://www.neogaf.com/forum/showthread.php?p=135388408#post135388408

 

[Krejlooc]

So, I followed the instructions as described. Either I missed a step or a step is missing from the guide - the initial install steps assume that you've cloned the git repo into a subdirectory of your home directory, but later steps assume the toolchain lives in /usr/local/dc.

EDIT: Sneaky. I see you fixed the instructions. Never mind. I have it working as the instructions describe now.

Yup, thats why I wanted to make sure I built the toolchain again per my own instructions, to make sure they were accurate. I built the toolchain on a few pcs last night and found a few things - namely that cygwin x64 is very unstable. We'll need to be using cygwin x86 instead. On top of that, there is a patch for windows 8 that i'm going to try when I get home again.

Always good to make sure everything is working and we're on the same page