Sign in to follow this  

256 or 16 bit color in assembly language

This topic is 4479 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
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 ?

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ?)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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 ^^^

Share this post


Link to post
Share on other sites

This topic is 4479 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this