256 or 16 bit color in assembly language
Author
Hi All !
How to put pixel in 256 or 16 bit color on screen by using assembly language ?
Thank you.
Uhh.. That depends on which environment you're coding in.
If you're using Win32 then you probably want to use GDI, DirectDraw or D3D just like you would in a 'regular' C or C++ application.
However for a DOS application you'd use 'mode 13' or a VESA mode instead.
If you're using Win32 then you probably want to use GDI, DirectDraw or D3D just like you would in a 'regular' C or C++ application.
However for a DOS application you'd use 'mode 13' or a VESA mode instead.
Author
If I used GDI, DirectDraw or D3D, C or C++ application, is it would slow down the speed ?
Briefly explain how to code it ?
Where can I find the mode 13' or a VESA mode information? Any link recommend ?
Briefly explain how to code it ?
Where can I find the mode 13' or a VESA mode information? Any link recommend ?
Maybe I should restate my question. Are you coding for the Windows platform, for DOS or something else entirely?
What's your target platform? If you've got direct hardware access (i.e. DOS, OS drivers) then VGA/VESA is how you'll want to do it. Otherwise you'll have to use an API provided by your platform (so X11 for most Unixes, GDI/D3D/DDraw for Windows).
Edit: beaten by 15 seconds.
Edit: beaten by 15 seconds.
Author
It is for learning purpose. Normally I using windows platform.
In the speed wise, what is the different between API and using the assemble language ? (I mean, if found that some subroutines is slow when using directx, is it possible to use assemble language instead ?)
In the speed wise, what is the different between API and using the assemble language ? (I mean, if found that some subroutines is slow when using directx, is it possible to use assemble language instead ?)
Quote:Original post by kslam
In the speed wise, what is the different between API and using the assemble language ? (I mean, if found that some subroutines is slow when using directx, is it possible to use assemble language instead ?)
There's no difference between calling one API function from C and the same API function from assembly language. However in some cases (albeit not very often) it's possible to implement certain things faster yourself using software rendering.
If want to mess around with software rendering in assembly language then I suggest that you only use your graphics API to provide basic frame buffer access. And just implement the rendering functions themselves, instead of the entire application, in ASM.
When you get access (via API) to the frame buffer or surface you can use the language you want (C, C++, asm, a mix...). It's simply a 'mem set stuff'.
I dont see the problem.
Remember that is not always true ( often it's false) that asm give you 'incredible speeds'; if you use the API you can use HW acceleration for 'expensive' 2D operations (like blitting of large images).
And probably the compiler knows asm (and processor extensions) better than you (or me) [smile]
I dont see the problem.
Remember that is not always true ( often it's false) that asm give you 'incredible speeds'; if you use the API you can use HW acceleration for 'expensive' 2D operations (like blitting of large images).
And probably the compiler knows asm (and processor extensions) better than you (or me) [smile]
In most modern OS's you don't get direct access to the screen. You need to go through the OS. Calling whatever OS api draws stuff to the screen in assembly is no faster than doing the same thing in C or C++ or whatever language you prefer.
VESA, mode 13, mode X, etc. mostly only matter in DOS. If you're not programming in DOS you probably can't use them.
VESA, mode 13, mode X, etc. mostly only matter in DOS. If you're not programming in DOS you probably can't use them.
The good new is that also the older DirectDraw versions ( the most used API for Windows* ) supports the old skoolz glorious Mode 13h (13h is the interrupt number used in DOS days) as well as a lot of 'ancient' video modes.
If you like retro art you can create the frame buffer (as primary surface), get the pointer to access its memory and use your assembly.
(*)...but OpenGL is much better **
(**) I'm joking...ignore ^^^
If you like retro art you can create the frame buffer (as primary surface), get the pointer to access its memory and use your assembly.
(*)...but OpenGL is much better **
(**) I'm joking...ignore ^^^
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
