- Non-English source :/
- having PutPixel as a procedure call is bad for speed... you really should keep that inlined, and preferably work directly on pointers instead of constantly calculating index based on x/y.
- instead of doing all the DC and Bitmap flaffing around in WM_PAINT, you can create a DIB section at start, and then simply keep the pointer around, and do a single BlitImage call in WM_PAINT.

The effect is neat-looking though, reminds me of my turbo-pascal and mode13h experiments all those years ago

Yes, sorry, a bit lazy lately... I have noticed, though, that it doesn't worth this effort.

Quote:

- having PutPixel as a procedure call is bad for speed... you really should keep that inlined, and preferably work directly on pointers instead of constantly calculating index based on x/y.

Well, we need calculating every time the pixel colour for the motion. I have another version where the whole data is calculated only once, but then we need calculating two sides everytime from there... once again for the motion.

Quote:

- instead of doing all the DC and Bitmap flaffing around in WM_PAINT, you can create a DIB section at start, and then simply keep the pointer around, and do a single BlitImage call in WM_PAINT.

Do you mean creating DIBSection in wmCreate, for example? But, don't we need HDC for creating DIBSection, generated in BeginPaint, inside wmPaint?

Quote:

-The effect is neat-looking though, reminds me of my turbo-pascal and mode13h experiments all those years ago

Yes, this effect comes from qbasic (algorithm original from Toni Gual... thanks Toni), as I said in my credits (in spanish), sure...

Well, I'm learning doing demos, not much time for it, but I stand If you have any other comments or even if you want wasting time to reorganize this code I could translate this to english for you (don't ask me to translate it to danish or german... he he, it would be so hard surely ). Any constructive criticism or stuff would be welcome.

By the way, great days those from 13h. Although many people desestimate qbasic, it has great codes, as well as turbo pascal, asm etc. And I think that Microsoft has taken a poor decision not supporting 16 bits in its newer OSs... lost much excellent stuff...

Yes, sorry, a bit lazy lately... I have noticed, though, that it doesn't worth this effort.

IMHO it's a good idea to keep comments in English, especially if you want to share your creations with the world. And even if you don't, it's training . I know some people are going to disagree with me, but English is the lingua franca (heh!) of programming. I've been doing so myself in most stuff for those almost 20 years I've been programming (wow. Am I that old now? )

avcaballero wrote:

Quote:

- having PutPixel as a procedure call is bad for speed... you really should keep that inlined, and preferably work directly on pointers instead of constantly calculating index based on x/y.

Well, we need calculating every time the pixel colour for the motion. I have another version where the whole data is calculated only once, but then we need calculating two sides everytime from there... once again for the motion.

Even if you need X+Y for calculating the effect, it's going to be faster to advancing them along with advancing a pointer to your pixel buffer - two INCs in the innerloop instead of an INC and pixel-offset-calculation . Heck, even if you're out of registers and spill X+Y to local variables...

avcaballero wrote:

Quote:

- instead of doing all the DC and Bitmap flaffing around in WM_PAINT, you can create a DIB section at start, and then simply keep the pointer around, and do a single BlitImage call in WM_PAINT.

Do you mean creating DIBSection in wmCreate, for example? But, don't we need HDC for creating DIBSection, generated in BeginPaint, inside wmPaint?

You can save the HDC for the DIBsection, then you only need BeginPaint() (which gives you screen HDC), BlitImage(), EndPaint() in your WM_PAINT handler. You can get the HDC needed for creating the DIBsection from CreateDC(0), which gets the DC for the default monitor.

avcaballero wrote:

Well, I'm learning doing demos, not much time for it, but I stand If you have any other comments or even if you want wasting time to reorganize this code I could translate this to english for you (don't ask me to translate it to danish or german... he he, it would be so hard surely ). Any constructive criticism or stuff would be welcome.

Don't translate it for me, or anybody else - translate it for yourself! . Btw, I'm glad you're taking this as constructive criticism, as that's how it's meant.

avcaballero wrote:

By the way, great days those from 13h. Although many people desestimate qbasic, it has great codes, as well as turbo pascal, asm etc. And I think that Microsoft has taken a poor decision not supporting 16 bits in its newer OSs... lost much excellent stuff...

Mode 13h was fun - "An elegant weapon, for a more civilized age"

I've never seen any basic code (any dialect) that was nice, but decent enough [i]end results[i] have been achieved . My own Pascal code wasn't much better, which is no wonder considering it's the first language I touched, but the language (at least Object Pascal) makes it possible to write decent enough code.

Changed a bit in the code of the cube, it will now auto detect the highest refresh rate on your system and at the highest resolution for that refreshrate. Also changed the rotation code from using the fpu into using sse instead, in between endscene and present to improve parallism of cpu and graphic accelerator. Also changed texture.

You have to install d9. It has been tested on various machines, including win 7 32 and 64 bit, works well. I use 306.97 myself and a gtx 680 amp edition. You need latest d3dx9 version 43. I enforce hardware acceleration, if your card does not support it it will fail. It is also worth noticing that the automatic detection routine will find the highest refreshrate and the highest resolution for that refreshrate, if it does not support hardware acceleration with that it will also fail. That is how it goes with simple examples like these, it is not something that is designed with industry quality fail-safe behavior

Your firewall may be blocking parts of direct3d9 due to faulty behavior. Comodo firewall is one of them who have faulty direct3d filtering, resulting in a black screen. If you use comodo, turn off defense+ to see if that solves it.

Your firewall may be blocking parts of direct3d9 due to faulty behavior. Comodo firewall is one of them who have faulty direct3d filtering, resulting in a black screen. If you use comodo, turn off defense+ to see if that solves it.

Ummm... firewall blocking d3d9? In which universe? Is this the point where I should start being suspicious of your files? (I'm using the built-in Windows Firewall, anyway).

Installed the latest DX redist I could find, (June 2010), which should be plenty fine for anything DX9... still, no go.

Comodo protects com interfaces, do a google if you are unfamiliar with it. I have tested both cube and corridor on two different machines, one on windows 7 32 bit and one on a laptop with windows 64 bit, both works good, the laptop have a crappy graphics card not designed for dx, and it still works well. It has also been tested on 8 machines by other people, in all cases it works as well.

What error message do you get when it runs and what background color is rendered when it runs?

Comodo protects com interfaces, do a google if you are unfamiliar with it.

Interesting! - that's functionality beyond "firewall", though, even if that's what they call their product

nmake wrote:

I have tested both cube and corridor on two different machines, one on windows 7 32 bit and one on a laptop with windows 64 bit, both works good, the laptop have a crappy graphics card not designed for dx, and it still works well. It has also been tested on 8 machines by other people, in all cases it works as well.

Some drivers are more forgiving than others, I guess

nmake wrote:

What error message do you get when it runs and what background color is rendered when it runs?

I don't get any error messages - all of the samples change video mode (obvious since my secondary monitor shifts around a bit), but all I get is a black background until I hit ESC.. Cube tells me "Best resolution detected: 1280x1024x32 @75Hz" before changing resolution. Process Explorer shows no GPU usage while cube is running, but CPU usage goes from ~3% idle to ~14%, which is a bit more than a single maxxed-out core (i7 with hyperthreading).

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou can download files in this forum