🔒 Locked

A simple Asm question

Started by Crispy Jul 22, 2002 at 11:08 AM 8 replies 250+ views

Original Post

170

Jul 22, 2002 at 11:08 AM

I''m fooling around with this sample program that initializes the screen by setting it to mode 13h. The fact that 13h equals 320*280, 256 colors per active palette, is pretty much the only thing I know about asm. I don''t want to learn assembly, not at the moment at least, but I would like to set up some more advanced screen graphics. Is it possible to set the screen mode to 1152*864, 32 bit by simply pushing-popping-moving stuff? I know you can''t do it in Basic, and since afaik, you had to set the screen mode in asm, so there you have it.. (Note: I never really learnt Basic

). PS - Assembly source would be most welcome, if someone has time to spare... Thanks for any help, Crispy

merlin9x9

Jul 22, 2002 at 11:19 AM

If you intend to run whatever your making under anything but pure DOS, then there''s essentially no way. Windows, for instance, will either complain or the app will freeze. Under DOS, to access modes like that you can''t just tell the BIOS to set the display mode to x by y at z colors because the BIOS essentially only handles up to VGA. Beyond that you''d need to use VESA modes. At that point, you''re talking about serious programming because frame buffer layouts differ between adapters, etc. So, if you want high-res, just use the APIs of a GUI environment, such as Windows or X.

JonStelly

Jul 22, 2002 at 11:36 AM

"and since afaik, you had to set the screen mode in asm"

That''s not right. Windows has DirectX as well as a Win32 function call to change the resolution (don''t remember the function name off the top of my head). Linux / X Windows / Mesa must have something similiar, but your guess is as good as mine there.

Puzzler183

Jul 22, 2002 at 12:21 PM

First off, Mode 13h gives you 320x200x256. Look up ralph browns interrupt list. You should find a lot of info there.

LordLethis

Jul 22, 2002 at 12:37 PM

The Win32 function to change the resolution is ChangeDisplaySettings/ChangeDisplaySettingsEx. You need to pass a pointer to a DEVMODE structure and some other stuff.

Those who do not love don''t live.

Crispy

Author

170

Crispy

Jul 22, 2002 at 12:43 PM

Ok thanks, guys - it can''t be done (not by me, at least) - that''s all I wanted to know. It''s just that if I port all the drawing stuff to Windows, I''ll have to start messing with the API code + drawing in a HDC the speed of which doesn''t at all encourage me. Hmm I wonder (haven''t checked yet) - how does Quake 2 draw its buffer. Does it draw it in a HDC and then lets Windows do the blitting or does it access video memory directly, overriding the Windows window system...

Crispy

Sneftel

296

Sneftel

Jul 22, 2002 at 12:57 PM

quote:
Original post by Crispy
Ok thanks, guys - it can''t be done (not by me, at least) - that''s all I wanted to know. It''s just that if I port all the drawing stuff to Windows, I''ll have to start messing with the API code + drawing in a HDC the speed of which doesn''t at all encourage me. Hmm I wonder (haven''t checked yet) - how does Quake 2 draw its buffer. Does it draw it in a HDC and then lets Windows do the blitting or does it access video memory directly, overriding the Windows window system...

Crispy

ehehe... games that require realtime redraws don''t use GDI. Quake 2 uses OpenGL, if I recall correctly. DirectX is also an option. Respondents who try to start an OGL/DX flamewar will be slapped.

Crispy

Author

170

Crispy

Jul 22, 2002 at 1:04 PM

quote:
Original post by Sneftel
ehehe... games that require realtime redraws don''t use GDI. Quake 2 uses OpenGL, if I recall correctly. DirectX is also an option. Respondents who try to start an OGL/DX flamewar will be slapped.

Correction - Q2 supports PowerGL (whatever that is), OpenGL, 3dfx and veeery nice software mode. The latter was what I had in mind...

Oh and, no DX (original Q2, that is - I don''t know about patches and stuff, though - I''m not a real games fan)

quote:
Original post by Sneftel (again)
ehehe... games that require realtime redraws don''t use GDI.

Take a look at Unreal''s software mode. I personally can''t even start to figure how they manage to pump up performance that much!

Crispy

merlin9x9

Jul 22, 2002 at 1:23 PM

quote:
games that require realtime redraws don''t use GDI

Actually, you can get extremely good performance by using a DIB. In fact, before DirectDraw appeared, this was the preferred way to do high-performance graphics in Windows, since it allows you to directly modify the pixel data—which is the exact same thing that DirectDraw lets you do, but at a slightly higher level.

GarlandIX

Jul 22, 2002 at 1:31 PM

quote:
Original post by Crispy

[quote]Original post by Sneftel (again)
ehehe... games that require realtime redraws don''t use GDI.

Take a look at Unreal''s software mode. I personally can''t even start to figure how they manage to pump up performance that much!

Crispy

You actually can get a lot out of GDI if you know what you are doing. IIRC, you can get a lot of speed when using DIB sections for drawing and Memory DCs for double buffering.

------------------------------
BASIC programmers don''t die, they just GOSUB and don''t return.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.