Re: Windows Assembly

What kind of game/s are you interested in? 

A 3D game with sound and networking.

Why is C a real pain?  There are tutorials for
game playing programs in C and even using C in
a DirectX shell for games.


Well, I like it for the reasons I listed earlier.

Mostly what I don't like is GCC. It prints out all of these error messages which don't make a bit of sense, even after I figure out what I've done that it doesn't like. Should I do something as trivial as type "if (var1 == 12 and var2 == 14) {" then it starts complaining about every single line in the file rather than simply tell me that it doesn't know the word "and".

Then there's the standard library. For some reason half of the functions like to return -1 on error, which is a real bitch once you've gotten into the habit of typing "unsigned" in front of everything. Sometimes it's especially stupid, like in the case of functions that return a pointer. Pointers are unsigned.

Then every time I make a new function, I have to type a prototype for it at the top of the file, and every time I make a new global variable, that has to go at the top of the file too. We've had two-pass assemblers forever, why not a two-pass C compiler?

NASM is a real bitch if you try to make a multi-file program, because for global function or variable, you have to type a "global" for it in the file it's in, and an "extern" for it in all of the other files, and you can't just make one file to include in all of the others, because NASM gets mad if you "extern" something that's not external. However, I managed to write a perl script to go through all of my source files and generate include files for them, so to make something global now, all I have to do is type the word "vernix" in front of it and all of that is taken care of. I could do something similar for C, but I'd still be left to deal with GCC.

My main concern is that my C code isn't going to be as reliable as my assembly code. It's easy to type something in C that looks like it will work right, but it doesn't. Like this:

if ( (pointer = mmap(this, that)) < 0 ) {

That comparision is always false, because pointers are unsigned, yet for some reason that's one time that GCC doesn't bother to print a warning. So I can write error checking code, assume it works, and never know better until the day comes that the code screws up because it failed to detect that error. Imagine if I were writing really important data to a file via that mmap. I'd lose it all when the program segfaulted trying to write data to 0xFFFFFFFF.

Also, memmove() somehow found a way to bypass my segmentation fault handler while I was doing direct VGA access in Linux, and that signal handler was vitally important to making sure the VGA mode was restored in the event of a program crash. I have no idea how memmove() did that, but I test it by putting a line like "volatile *crash = NULL; crash++" before the memmove() and after it. Before it the signal handler was called correctly, after it the signal handler was never called and the program just segfaulted. I'm left to wonder how many other mystery bugs there might be in my program like that. I didn't do anything wrong, and my code looks totally correct, yet the error handling isn't going to work like it's supposed to.

I like to write programs that detect errors and act appropriately, but because of the above two items, I don't know that I can do that in C.

So you use NASM and haven't used Windows I assume
this means you have only used DOS?

No, I've been using Linux for the last five years or so, and so all of my programming has been done there.

It's just that I decided to make this game, and since it's 3D, I think it's pretty important that 320x240x256 be one of the modes that it's capable of running in, because nobody likes a slow game. I'd like to make the game shareware so that I can possibly make a little money from my work, and was at first quite content to simply try to sell it to Linux users. However, here's where video support is in Linux:

Linux consoles have two modes of operation: plain text, and vesa framebuffer.

If you're in plain text mode, there's SVGAlib, but SVGAlib doesn't do low resolutions like 320x240x256. However, in plain text mode, you can do direct VGA access, which is what SVGAlib does. Because of stupid kernel behavior, it's a real bitch to get working right, aparently even the SVGAlib authors still haven't gotten their code to not crash randomly if you switch consoles too quicky, but I've written some code that does it without a problem. The only problem with this method of access is that you only get 320x240x256 or 640x480x16, but I'd like for people playing my game to be able to choose between several resolutions.

If you're in framebuffer mode, you get one and exactly one high resolution mode to work with. The kernel doesn't share this between applications, so to access it you basically have to do everything that you have to do to make direct VGA access work, but like I said, I already had that taken care of. The problem with framebuffer is that it's always going to be a higher resolution than 320x240, and you can't change the resolution without rebooting the computer. So if someone's running in 1600x1200, then the game has to run hi-res and slow, and can't possibly offer them an option to switch video modes.

Now there's X which will run in either plain text or framebuffer. X sometimes offers you the option to change video modes, and sometimes it doesn't. It depends. If X is simply using the framebuffer, then naturally it can't change video modes any more than I could myself. If it's doing direct hardware access, then it can change modes, yet for some reason, on the computer in the other room, it won't. So X might sometimes be able to switch modes, but other times it wouldn't. On the plus side, when it is able to switch modes, 320x240 is an option, at least on my computer.

Then there's SDL, which is basically just a wrapper for SVGAlib, framebuffer, and X, using whichever it needs to at startup. So naturally, it doesn't offer any more flexability with mode selection.

So I'd be writing a game for a small segment of the population, and then an even smaller segment would be able to run the game in a resolution that actually made it fun to play, the rest would be stuck with either a tiny 320x240 window on their 1600x1200x24 display, or they'd be running it full screen and really slowly on their 1600x1200x24 display. Neither sounds like a situation where someone would send me a few bucks for the game.

Then the sound support sucks too, in ways seemingly no Linux person is capable of understanding, since they all seem to think it's just fine. Also, the KDE sound daemon seems to like to totally keep the sound device all to itself, so not only would I have to know how to access the sound device directly, I'd also have to know how to go through KDE. The flash player when playing sound isn't able to sync the sound to the animation (meaning I can't watch homestarrunner.com in Linux without going mad), so I'm sure that getting synchronized sound must be as much of a bitch as getting a good video mode.

So I figure, *** Linux. It wouldn't be worth the effort. I just go write the game in Windows, get a larger population to sell it to, actually have the thing work correctly on everyone's computer who wants to play it, and as an added bonus, I'm not stuck trying to market the game to a bunch of people who are so against paying for software that they make their software download tools not list shareware by default.

I wouldn't want more than $5 for the game, and it'd be a 3D network game, so it's not like it'd be overpriced, yet half of the Linux population wouldn't even consider it. The other half would probably think that since I wrote it for a free OS, that I somehow owe them and they should just get the game for free, and thus they'd never pay for it. Now if Linus Torvalds sent me an email saying "Hey, I wrote Linux, don't you think I should get a copy of the game for free?" I'd send him a registration code for it, but the average Linux user hasn't done anything for free software besides use it, and so they aren't entitled to get anything for free.

With all of that to look at, it's no wonder game developers ignore Linux. I went into this wanting to make a game for Linux, and in the end, my desire to make a game is causing me to switch from Linux to Windows. It'd be easier to write on Windows (I assume), it'd work better on Windows, and people would be more likely to actually pay for it on Windows. Linux simply doesn't have any advantage.

To what extent you need all that Window stuff
depends on the kind of game you want to write.

Basically, I'm just looking to get my choice of graphics mode without having to resort to direct hardware access. With a modern OS, I shouldn't have to do that sort of thing.
.