• ### Announcements

#### Archived

This topic is now archived and is closed to further replies.

# Programming graphics in assembly

## Recommended Posts

Hi, I''m not sure if anyone will be able to help me out on this, but I have a couple of questions about programming graphics in assembly. First the basic underlining question thats been nagging me for a while...apparantly, portions of Quake II''s graphic engine- specifically 320X240 software mode, is programmed in assembly. I seen a few differant references to it using 13h. Additionally, I have seen referance to ModeX (there is a console command for toggling ModeX..). The part that has me stumped is this; Quake II is a Win32 program (Unless its not, in which case Im really confused). From what I understand it was programmed in VC++5. However, VC++5 doesn''t allow you direct access to the BIOS, so you cannot do anything like this: void main() { _asm { mov ax, 13h int 10h } } (I tried and it crashed to blue screen ) How on earth did ''Id'' do it? Perhaps they used a DOS compiler and still were able to have a Win32 executable? In this case I am really confused. The second question is, does anyone know for sure, how Quake II plots pixels in software (non-OpenGL) mode. Is it 13h, ModeX, or something else entirely? Also, if anyone knows what compiler(s) Id used on Quake II''s graphics and executable code- not the DLL which I''m sure they used VC++5 on, that would help emmensely. Thanks

They must have just used external assembly and linked it at build time. And as for the pixel plotting in 13h, you just write a byte to memory at the screen offset+video memory base address( aka in pascal mem[$a000: y*320+x] = colbyte. Or you could use a pointer to vidmem..... #### Share this post ##### Link to post ##### Share on other sites Quake 2 most likely used DirectDraw to get a pointer to a drawing surface. From there, you can manipulate bytes just like the good ol'' DOS days (well, almost ...) #### Share this post ##### Link to post ##### Share on other sites quake2 DID use direcdraw. it was used for screen mode changes as well as software mode stuff. oops i should mention the only parts they used assmebly was for doing the actual rendering and other maht stuff. NO assembly that accessed interrupts was used (since windows dont let you access most of them without doing some dangerous tricks) Edited by - a person on December 10, 2001 3:19:24 PM #### Share this post ##### Link to post ##### Share on other sites Just to make this clear, bdrewes, Quake [one, as it were] was originally written to run in a non-gui x86 enviroment (just DOS and UNIX I think), and as you stated used mode 13h for some resolutions & ModeX for others (presumably too a number of SVGA funcs to manage higer resolutions). There''s a copy of the Quake I source code to download at ID where Carmack has adapted it to use OpenGL - partially as a test run for Q2 I believe. Quake II on the other hand was written with Windows (+unix?)(specifically OpenGL) in mind and so did not use the interrupts. I believe that the software render rendered to a DirectDraw surface. DirectDraw surfaces also happen to handle a ModeX style format - presumably originally to support legecy code. #### Share this post ##### Link to post ##### Share on other sites quote: Original post by Anonymous Poster They must have just used external assembly and linked it at build time. And as for the pixel plotting in 13h, you just write a byte to memory at the screen offset+video memory base address( aka in pascal mem[$a000: y*320+x] = colbyte. Or you could use a pointer to vidmem.....

Actually, they probably didn''t do that as Windows won''t allow it. Even if you use an external compiler, it won''t. As someone already mentionned, they probably used DX or some other windows trick...

Anyhow...

"And that''s the bottom line cause I said so!"

Cyberdrek
A division of DLC Multimedia

Resist Windows XP''s Invasive Production Activation Technology!

"gitty up" -- Kramer
/(bb|[^b]{2})/ that is the Question -- ThinkGeek.com

##### Share on other sites
Okay, this might seem like a stupid question, but why use Assembler for graphics programming? Wont that mean forfeiting use of hardware acceleration available from the graphics card?
But perhaps you just want to use it for software mode in a game?

##### Share on other sites
quote:
Original post by Ziphnor
But perhaps you just want to use it for software mode in a game?

Exactly.

##### Share on other sites
Thanks everyone, I hadn''t realized there was any DirectX coding in Quake II.

Ok, what a person wrote about them using assembly --only for doing the actual rendering and other math stuff and not for accessing interrupts...if Quake II didn''t use assembly and instead used what I understand to be a sort of DirectDraw ''emulated ModeX or 13h'', then where does this assembly stuff come into the picture?

Might there be big pieces of assembly code actually sitting in the Quake II source, or is there only DirectDraw code?

The part I''m interested in is the actual rendering and math stuff (i.e., putting a pixel on the screen in software mode and manipulating it), so basically, my question now is, if I were to write a program, using DirectDraw to manipulate bytes, I would be in essence plotting pixels the same as if I were programming 13h in DOS?

Also, would you need some version of DirectX installed to run a program like this? I don''t remember that Quake II required it..

##### Share on other sites
One other question:

Because DX 8 and the versions afterwards do not have DirectDraw, can you still do modex and 13h stuff?...Or has that capability finally been completly killed off.

Oh and ... *bump*

##### Share on other sites
DirectDraw is still alive and kicking... you can use mode 13h if you like but I don''t see why you would. In DDraw, it''s a cakewalk to use any resolution, but if it''s 320x200 you want then its all there. Check out this article: http://www.gamedev.net/reference/articles/article589.asp

This will literally hand you everything you need and answer all your questions.

BTW, there''s really no need to worry about assembly yet. You can write your entire game in whatever language and get it to work solidly. After your done, you can look at the areas of your program that are hurting your frame rate and use assembly language to optimize them. Back in the old DOS days, I would write entire games (albeit small games) in assembly. These days it''s REALLY not necessary. Computers are so fast that the bulk of your code can be in C++ and the game will be good enuff. If you want to target an audience with older computers, then go assembly crazy.

Good luck!

Many of the truths we cling to depend greatly on our own point of view

Get Tranced!

• ### Forum Statistics

• Total Topics
627749
• Total Posts
2978912

• 10
• 10
• 21
• 14
• 14