News:

MASM32 SDK Description, downloads and other helpful links
MASM32.com New Forum Link
masmforum WebSite

Suggestion for cool/fun graphics and effects ?

Started by BlackVortex, November 18, 2008, 04:34:23 AM

Previous topic - Next topic

BlackVortex

So, I'm getting bored of my simple programs/projects. I'd like to spice things up a little with some simple 2D gfx magic. Like, for example my Help>About function will show a little window with blinking stars, scrolling letters or whatever.

What is the easiest way to do this in asm ? OpenGL ? Directdraw ? Software rendering ? Are there any asm libraries to simplify the work ?

Tedd

Depends exactly what you're aiming for. A simple starfield is pretty simple using just the plain old gdi, and performance is fine once you get the hang of using a memory bitmap and bitblt from the back-buffer to avoid flicker.
DirectDraw is considered obsolete. OpenGL and DirectX have support for 2D graphics in the form of an orthographic mapping and textured polygons for the sprites - which is treated by the graphics card the same way as 3D graphics, so you get hardware support. And then you can start adding blending effects, etc. But, it's quite a bit of work just to get a simple scene set up.
If you can handle SDL http://www.libsdl.org/ it can save you a lot of messing around (and Japheth has made some include files http://www.japheth.de/Win32Inc.html [bottom of the page])
But I'd start with gdi first :wink
No snowflake in an avalanche feels responsible.

BlackVortex

I totally forgot about gdi !  I think that's the way to go ! I'm on it, whanks  :-D

slovach

Quote from: BlackVortex on November 18, 2008, 01:38:25 PM
I totally forgot about gdi !  I think that's the way to go ! I'm on it, whanks  :-D

If you are going to use GDI, you're going to have a hard time with speed unless you are careful. SetPixel for instance is hideously slow.

The fastest way I've found is using a DIB, and manipulating the bits. It's a bit of a pain to work with, since you need to calculate all the bitmap quirks your self, but it's simple enough, and is far, far faster than any of the built in GDI functions. You can easily implement things like alpha blending from there, and if you are careful with how you draw the scene, you can do the entire thing in one blit, transparency and all.

Rockoon

Technically you don't need to use a DIB object.

GDI32's SetDIBitsToDevice()

This is the fastest and simplest way I have found to render a buffer from system memory under *ANY* API (GDI, SDL, OGL, DX), and you never have to create/manage an hBMP or muck around with any other GDI objects besides the destination hDC (aka the device recieving the pixels)

You will need to manage a BITMAPINFO structure, but that can be made constant in your data section and pre-initialized.

Some things to note:

This thing defaults to bottom-up rendering (bottom scanline lowest in memory) instead of top-down (top scanline lowest in memory), so you need to give it a negative height.

This thing WILL perform pixel conversions if the destination format does not match the source (at least in my own experiments with 16bpp -> 32bpp), and do it just as quickly (possibly hardware accelerated)

This thing will even render PNG and JPG data directly, just like in a DIBSection.

This thing will NOT perform any scaling tho (but in my experience, GDI scaling is always slower than manual)


IMHO, this is *THE* function to use for software-based rendering.
If OTOH you are trying to render lots of sprites, then it is clearly superior to use DX/OGL because system memory can be reliably be removed from the equation under those API's (GDI has mechanisms too, but no guarantee's... DDB's can be held in video memory, but you dont have exclusive access so you must share and risk eviction)
When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one.

u

sDraw
Please use a smaller graphic in your signature.

Mark Jones

Hey U, good to see you. sDraw is a great package -- fast, lightweight, and easy to use. It should be far more popular, and available to more people.

So, over the past few days I have been converting the sDraw v1.2 release into GoASM syntax, with complete RadASM sample projects / intellisense / hilighting / auto-completion. The C example is still being converted, but everything else is working. GoASM is a great assembler, and sDraw is an enabling technology... so it just seemed fitting to marry the two together (even if this only means a few additional users.) :bg

Curious U, are there any updates or additions available since the 1.2 release?
"To deny our impulses... foolish; to revel in them, chaos." MCJ 2003.08

BlackVortex

Heh, I just drooled over your Example2 (asm) in the package  :-D


u

Quote from: Mark Jones on November 27, 2008, 06:11:32 PM
Curious U, are there any updates or additions available since the 1.2 release?
Just changed the Y axis of drawing to be top-bottom internally (negative height of that DIB and all code fix-ups that follow from that), added a faster line-drawing proc, made the previous line-drawing do antialiasing, added splines and drawing of splines with "shaders" (callback procs). Started to change and expand the drawing of text. This version is still WIP, not ready for public.
Please use a smaller graphic in your signature.

BlackVortex

@ u

I've been learning your library and it's awesome !

I'm trying out things and when I finally manage to get them right I'm like this   -->    :cheekygreen:

Waiting for version 1.3    :thumbu