Assembly coded project

Sounds very simple and very doable to me.

EDIT: Disclaimer: I've never written much assembly at all

Space Invaders?

Quote:

Original post by wizardpc and vga 8 colors.

That statement implies to me that you are expecting to take some old DOS code and try copying it to write directly to the VGA buffer. You can't do that on modern OS's. You conceivably write a 16-bit app and let Windows' DOS emulation kick in but I don't really see the point. Plus you'd have to find a 16-bit assembler.

Your game idea seems reasonable. I was going to suggest Pong but that is even simpler.

Quote:

i heard that it takes about 10 lines of assembly code to write about one line of code in c++

It depends a great deal on what that line of C++ does. It could translate to 1 assembly instruction or thousands.

From what little I've coded in assembly that seems like a very reasonable goal.

This concept seems reasonable. I'm already figuring out in my head how to do it. I recommend starting by writing the appropriate C and converting it to assembly by hand, which is what I did in my various university courses regarding i386 and sparc asm.

Keep in mind that direct VGA access won't work on NT and other semi-evolved operating systems; you can probably use DosBox but you should be aware of this limitation.

Quote:

Original post by Anon Mike Plus you'd have to find a 16-bit assembler.

NASM can compile both 32-bit and 16-bit code. It would work perfectly for this sort of thing...

You can always set up the VGA mode in real-mode, and then go into protected mode for the rest of the game. This is assuming, of course, that it will not be running on a modern 32-bit OS, which I assume does not allow a 16-bit app running under emulation to thunk into protected mode...

Quote:

(please no networking / MMORPG/ flight sim)

Damn, I was hoping you'd write a WoW clone ;)

You can always use DirectDraw from assembly in order to present your "video memory". That's what Windows ports of old DOS games do (well, they don't do it in assembly, but it's compiled, so there's little difference.)

Quote:

Original post by Ravuya This concept seems reasonable. I'm already figuring out in my head how to do it. I recommend starting by writing the appropriate C and converting it to assembly by hand, which is what I did in my various university courses regarding i386 and sparc asm.

That's a good idea. The only problem for a beginner will be incremental testing of the assembly code. What I would do after completing a C prototype is translate the graphics code first and test it by invoking it to draw some sprites around the screen. Then I'd begin working on the rest in a sort of outside-in fashion (relative to function call order.)

If wizardpc were experienced using GCC (DJGPP) and NASM, he could translate one function at a time and link it in with the rest of the C code.

Quote:

Keep in mind that direct VGA access won't work on NT and other semi-evolved operating systems; you can probably use DosBox but you should be aware of this limitation.

That's not true. Windows NT-based OSes (2K, XP) still allow you to run 16-bit and 32-bit DOS applications. Direct VGA access appears to be allowed, which means Mode 13h, Mode X, and other tweaked modes are usable. VESA is not usable.
Sound cards aren't usable (unless you run VDMSound); the PC speaker is.

Quote:

Original post by wizardpc do you think this would be easy to implement? is it too easy? i heard that it takes about 10 lines of assembly code to write about one line of code in c++.

a += b; C++, C#, Java

add eax, ebx any ASM



mov buffer, 0
invoke GL.CLEAR, buffer Macro ASM / advanced ASM.

mov GL.clearColor, GL.BLACK
call GL.clear ASM with GL programming in the mind


~TRIANGLES {
...
}
ASM with heavy GL programming in the mind.

Ask your teacher if you can use 64 bit ASM, and OpenGL. If yes it's piece of cake. Just 5 days more than using higher programming languages. (Setup of input and screen, and getting acustomed to your ASM.)

Quote:

Original post by trzy Quote: Keep in mind that direct VGA access won't work on NT and other semi-evolved operating systems; you can probably use DosBox but you should be aware of this limitation. That's not true. Windows NT-based OSes (2K, XP) still allow you to run 16-bit and 32-bit DOS applications. Direct VGA access appears to be allowed, which means Mode 13h, Mode X, and other tweaked modes are usable.

Direct VGA access isn't allowed, it's emulated. And even then only for 16-bit apps. 32-bit apps need to play by the modern rules.

Quote:

Original post by trzy That's not true. Windows NT-based OSes (2K, XP) still allow you to run 16-bit and 32-bit DOS applications. Direct VGA access appears to be allowed, which means Mode 13h, Mode X, and other tweaked modes are usable. VESA is not usable. Sound cards aren't usable (unless you run VDMSound); the PC speaker is.

XP offers sound card emulation. VESA modes are usually available (sometimes a fresh restart is required), but can sometimes crash back to the desktop (on older ATi drivers it would also scramble the desktop). I'm not sure how much of this is emulated. I know DOS Tomb Raider runs perfectly happily under XP with sound and high-resolution graphics.

Quote:

Original post by Anon Mike Quote: Original post by trzy Quote: Keep in mind that direct VGA access won't work on NT and other semi-evolved operating systems; you can probably use DosBox but you should be aware of this limitation. That's not true. Windows NT-based OSes (2K, XP) still allow you to run 16-bit and 32-bit DOS applications. Direct VGA access appears to be allowed, which means Mode 13h, Mode X, and other tweaked modes are usable. Direct VGA access isn't allowed, it's emulated. And even then only for 16-bit apps. 32-bit apps need to play by the modern rules.

Technicalities. Ever since Win9X, all 16-bit DOS code has been run in Virtual 8086 (V86) mode which is a feature of the X86 architecture that allows the OS to set up a segment of memory, run it in a 16-bit compatibility mode, and trap privileged operations. For example, the Windows keyboard driver still actually handles keyboard interrupts and passes the data to the V86 session when it attempts to read from the keyboard port. Whether VGA is actually emulated or eventually passed to the hardware directly (since VGA is ultimately supported by all modern cards) is irrelevant -- the bottom line is that DOS applications can still make use of it just as if they weren't running on Windows at all!

You're incorrect about 32-bit apps. Most of my DOS programs were 32-bit (I used DJGPP) and they're still allowed to access hardware directly in the same manner as 16-bit programs. Thanks to DPMI (DOS Protected Mode Interface), of which Windows is a server, 32-bit protected mode DOS programs can still be managed by Windows.

Quote:

Original post by benryves XP offers sound card emulation. VESA modes are usually available (sometimes a fresh restart is required), but can sometimes crash back to the desktop (on older ATi drivers it would also scramble the desktop). I'm not sure how much of this is emulated. I know DOS Tomb Raider runs perfectly happily under XP with sound and high-resolution graphics.

It must have been added since Win2K. My home system runs 2K and doesn't provide VESA or sound card emulation. I use VDMSound to get around the latter but haven't found a similar solution for VESA modes yet.

thanks for all the replies, i have made this game using directx and c++ so its pretty much just going to be rewritting it into assembly.


i wish i could discuss it more but like i said i know 0% of assembly and this is my first day in class. You guys sound like you know alot, i'll leave it open to you guys to discuss it any further.



thanks again

I did forget about Virtual 8086 mode and the VGA emulation; mea culpa.

I do like trzy's idea of stubbing out the functions and gradually replacing them with ASM versions.