Pixel Shader Programming

[Doomulation]

I gave up on windows registry a long time ago and moved to INIs... Saves a lot of unnecessary time...
Now, if you have a registry framework, why not consider adding OO (object oriented) INI functionality? (I could program it, it's easy as hell and should take me no more than one day including debugging for all of the common datatypes)

Yay, Joint projects.

But you know, true Object-oriented functionality for anything is not that entirely that easy. My take on it is to incorporate well-known data types and perform the saving for you.
For custom data types, they should be classes. By deriving from a known class, the framework can call a specific function to let your custom class do its own saving and loading. True OO way. No longer necessary to manually handle saving and loading of data.
But you know, INI files are just a pain to handle, not to mention they get big and are slow to read/write from.

 

[mudlord]

I've seen BASS included in commercial apps (games) before... Worked well for OGGs IIRC. If you'll use/embed too many toolkits/DLLs created by other people, your toolkit could turn into a collection of other toolkits. (or, if agreed by creators, a whole new framework) Anyway, sound files are an exception, just like DX/OpenGL.

BTW, have you already programmed your own controller, which exports one simple function like PlaySoundFile(file, bAsync) and associates different file and mime types to different sets of functions, which are exported by BASS and other modules?

Yes, BASS works extremely well for Ogg Vorbis files and streams...and I am aiming to keep the number of outside libraries to the absolute minimum. Which means that there is BASS/libv2 for sound and OGL/DX for graphics. Everything else, like the hash algorithms are custom made.

And yes, I am in the process of making simple calls for loading audio and playing it back. It will use a simple fallback method for sample streams and module music, while V2M arrays will be loaded seperately.

However, my main focus is on the Win32 things and graphics, especially Direct3D...

 

[mudlord]

Anyways...

I finally got around to rewriting this app.

All message handling is 100% fixed and I have added some extra hotkeys:

F1: Load shader
F2: Load graphics file

Shaders and graphics files can now be changed on the fly. Also, I have written a version (shadertestHWFB.zip) that:

* Makes a copy of the back buffer VERY fast into a DX9 render target surface (sorta like how framebuffer objects work in OpenGL)
* Post processes the render target texture
* Outputs the post processed texture
* Allows for pixel shaders to be toggled on or off....(press F3)

 

[xtra krazzy]

The problem with post processing the render target is that it loses the actual pixel shading. Of course, in your intranslatable (not being able to move?) viewport which contains one texture and one shading it works fine and fast, but it only applies to your case. (i.e. in a program which contains D3D UI, the UI components such as buttons will be shaded as well)

Add an FPS monitor

EDIT: You haven't handled WM_PAINT right

 

[mudlord]

i.e. in a program which contains D3D UI, the UI components such as buttons will be shaded as well

Ah hah, true.

Add an FPS monitor

Anything else you would like me to add?

You haven't handled WM_PAINT right

Au contraire! WM_PAINT is not being used at all.....

All it is is a simple case of D3D rendering straight into the window. No GDI used here

 

[xtra krazzy]

Au contraire! WM_PAINT is not being used at all.....
All it is is a simple case of D3D rendering straight into the window. No GDI used here

When I move the window beyond the screen, and return it while still holding the window (when WM_PAINT should be called), there's a clear, black segment of it, as if it's not being painted. Cannot think of a D3Die way of fixing it. Only GDIsh