DirectX 2D Framebuffer Library
Author
Hi, everybody!
I am programming a framebuffer library for VisualStudio Express with Direct3D 9 very similar to that of QuickBASIC. It uses a big texturized quad to show the screen contents, and bitmaps can be created in malloced arrays, much like the old DOS VGA libraries did.
It will be much simpler to use than SDL is, but in compensation it will have less features builtin. It is a simple system for domestic users, not professionals. It is written for amateur programmers like me, who want to learn how to make games like the old arcade games written in 80/90 decade, like the famous Mario everybody copies. :D
It have an option to hide the mouse cursor, currently it uses GDI for this feature, but I want to use DirectX for everything. The problem is, when I disable the GDI cursor with "SetCursor", I cannot enable and show it with "ShowCursor" and "SetCursorPosition", both of Direct3D (of course!). :)
Because of this, I ask: how can I control the Windows cursor from Direct3D? I must provide first a cursor bitmap to Direct3D, to make it work?
[Edited by - LeJa on April 22, 2010 9:04:31 PM]
If you're going with a DirectX or OpenGL method of getting contents to the screen, what method do you use to get bits from the framebuffer in system memory, onto a texture for the GPU?
Do you impliment a method to sync with the vertical retrace? This should be a major priority if you have not, as sync is really the only advantage a framebuffer system like this has for being written in Direct3D or OpenGL -- otherwise, win32 calls are sufficiently fast (but there's no way to detect vertical retrace, so your screen updates are susceptable to tearing). I also presume it's double-buffered to prevent flicker?
Are you able to account for any desired buffer size, or do you limit to available screen-modes? Are you accounting for stride being different than pitch?
Have you seen TinyPTC? I think it used to be called pixelToaster -- but it does the same thing you seem to have here -- simple linear framebuffer with read/poke pixel commands. Do you support any higher-level primitives like lines, circles, boxes, ellipses?
Finally, I hate to break it to you, but most of those old arcade machines and early consoles weren't framebuffer systems -- I think the first consoles (discounting early PC/semi-consoles like the Commodore 64) that had actual framebuffers would have been the 32/64bit era: Playstation, Saturn, N64. The early 2D systems and any 2D arcade platform I can recall (aside from the true vector-based ones) were based on tiles/sprites. Although as computer programmers we think of tiles and sprites as a software problem, they were actually implimented in hardware on these older systems -- In fact, their simple graphics units could only hold a fixed number of them, and very often you were limited to only a few sprites on a single line of the display (on the NES, you get something like 10 8-pixel-wide sprites per line). Long story short, Mario ain't no framebuffered chump [grin]
But at any rate, I'm not meaning to attack or dissuade here -- software rendering is something of an interest and hobby of mine -- just wanting to be sure you've covered your bases.
As for the cursor in Direct3D, I've always thought: Why bother with hardware cursors? You've got a framebuffer, and you know where the mouse is pointing, regardless of whether it's being drawn or not, so why not just give the clients access to the mouse coordinates and let them draw a sprite in that location themselves? Simplest solution to a simple problem -- plus you easily have high-color cursors, animated cursors... anything you want.
Do you impliment a method to sync with the vertical retrace? This should be a major priority if you have not, as sync is really the only advantage a framebuffer system like this has for being written in Direct3D or OpenGL -- otherwise, win32 calls are sufficiently fast (but there's no way to detect vertical retrace, so your screen updates are susceptable to tearing). I also presume it's double-buffered to prevent flicker?
Are you able to account for any desired buffer size, or do you limit to available screen-modes? Are you accounting for stride being different than pitch?
Have you seen TinyPTC? I think it used to be called pixelToaster -- but it does the same thing you seem to have here -- simple linear framebuffer with read/poke pixel commands. Do you support any higher-level primitives like lines, circles, boxes, ellipses?
Finally, I hate to break it to you, but most of those old arcade machines and early consoles weren't framebuffer systems -- I think the first consoles (discounting early PC/semi-consoles like the Commodore 64) that had actual framebuffers would have been the 32/64bit era: Playstation, Saturn, N64. The early 2D systems and any 2D arcade platform I can recall (aside from the true vector-based ones) were based on tiles/sprites. Although as computer programmers we think of tiles and sprites as a software problem, they were actually implimented in hardware on these older systems -- In fact, their simple graphics units could only hold a fixed number of them, and very often you were limited to only a few sprites on a single line of the display (on the NES, you get something like 10 8-pixel-wide sprites per line). Long story short, Mario ain't no framebuffered chump [grin]
But at any rate, I'm not meaning to attack or dissuade here -- software rendering is something of an interest and hobby of mine -- just wanting to be sure you've covered your bases.
As for the cursor in Direct3D, I've always thought: Why bother with hardware cursors? You've got a framebuffer, and you know where the mouse is pointing, regardless of whether it's being drawn or not, so why not just give the clients access to the mouse coordinates and let them draw a sprite in that location themselves? Simplest solution to a simple problem -- plus you easily have high-color cursors, animated cursors... anything you want.
Author
Hi Ravyne, your tips you gave me are invaluable, because I am amateur yet and there are some things I was not capable to guess, like the vertical sync. I do not knew also that many arcades machines were tile based, even most of them drawing a test screen full of tiles on startup. But for me, is sufficient to create a game that looks like the chump Mario :D, but that works differently.
I want to know how to handle the cursor using the Direct3D routines, because I saw that SDL does this, but I am unsure how it does this, mainly becuse SDL is pretty big and is getting bigger. But without doubt, drawing cursors with sprites is much more perfect. Anyway, I started to code this cursor, and I would like to know how its done, only for curiosity. You know how its done? How can I make the Direct3D cursor appear over the Window?
[Edited by - LeJa on April 23, 2010 3:27:09 PM]
I want to know how to handle the cursor using the Direct3D routines, because I saw that SDL does this, but I am unsure how it does this, mainly becuse SDL is pretty big and is getting bigger. But without doubt, drawing cursors with sprites is much more perfect. Anyway, I started to code this cursor, and I would like to know how its done, only for curiosity. You know how its done? How can I make the Direct3D cursor appear over the Window?
[Edited by - LeJa on April 23, 2010 3:27:09 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement