Tiny WinFloor demo

Index > Windows > Tiny WinFloor demo

Author

Thread

avcaballero

Joined: 02 Feb 2004
Posts: 214
Location: Madrid - Spain

avcaballero 20 Nov 2012, 08:26

Hello, here's my first approach to a WinFloor demo. Maybe interesting for the WritePixel routine into createdib memory.

Regards

Description:		Download
Filename:	TinyWinFloorDemo.zip
Filesize:	5.15 KB
Downloaded:	571 Time(s)

_________________
Siempre aprendiendo

20 Nov 2012, 08:26

DOS386

Joined: 08 Dec 2006
Posts: 1905

DOS386 20 Nov 2012, 09:54

COOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOL

20 Nov 2012, 09:54

avcaballero

Joined: 02 Feb 2004
Posts: 214
Location: Madrid - Spain

avcaballero 20 Nov 2012, 10:32

Thank you, Dos386 Smile

20 Nov 2012, 10:32

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 21 Nov 2012, 21:28

- 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 Smile

21 Nov 2012, 21:28

avcaballero

Joined: 02 Feb 2004
Posts: 214
Location: Madrid - Spain

avcaballero 22 Nov 2012, 08:50

Quote:

- Non-English source :/

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

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 Wink

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 Laughing

). 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...

Regards.

Description:		Download
Filename:	WinFloorDemo.zip
Filesize:	10.61 KB
Downloaded:	434 Time(s)

_________________
Siempre aprendiendo

22 Nov 2012, 08:50

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 22 Nov 2012, 19:12

avcaballero wrote:

Quote:

- Non-English source :/

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 Smile

. 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? Razz

)

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 Smile

. 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! Smile

. 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" Razz

I've never seen any basic code (any dialect) that was nice, but decent enough [i]end results[i] have been achieved Smile

. 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.

_________________
carpe noctem

22 Nov 2012, 19:12

avcaballero

Joined: 02 Feb 2004
Posts: 214
Location: Madrid - Spain

avcaballero 23 Nov 2012, 07:42

Quote:

translate it for yourself!

Huuumm, not for now....

Quote:

I'm glad you're taking this as constructive criticism, as that's how it's meant.

I'd give everything I know, for half of what I don't know. -- René Descartes

Thank you for advices, especially for creating DIB section using CreateDC(0)

Regards

23 Nov 2012, 07:42

nmake

Joined: 13 Sep 2012
Posts: 192

nmake 30 Nov 2012, 23:49

Speaking of floors, here is a bronze corridor, not dibs, this is direct3d 9.

Here is another one i've made, a spinning metal cube.

Description:		Download
Filename:	MetalCube.zip
Filesize:	158.72 KB
Downloaded:	453 Time(s)

Description:		Download
Filename:	Corridor.zip
Filesize:	184.95 KB
Downloaded:	447 Time(s)

30 Nov 2012, 23:49

nmake

Joined: 13 Sep 2012
Posts: 192

nmake 02 Dec 2012, 03:51

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.

Description:		Download
Filename:	Cube.zip
Filesize:	143.26 KB
Downloaded:	435 Time(s)

02 Dec 2012, 03:51

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 03 Dec 2012, 00:24

Neither MetalCube, Corridor nor Cube work here (win7x64, GTX460, nv306.97 drivers)

03 Dec 2012, 00:24

nmake

Joined: 13 Sep 2012
Posts: 192

nmake 03 Dec 2012, 00:37

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 Very Happy

03 Dec 2012, 00:37

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 03 Dec 2012, 00:47

Hm, I'm pretty sure I do have DX9 installed, will check tomorrow (heading to bed). I get nothing but a black screen.

03 Dec 2012, 00:47

nmake

Joined: 13 Sep 2012
Posts: 192

nmake 03 Dec 2012, 01:20

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.

03 Dec 2012, 01:20

avcaballero

Joined: 02 Feb 2004
Posts: 214
Location: Madrid - Spain

avcaballero 03 Dec 2012, 08:49

nmake wrote:

You have to install d9.

They don't work for me either, WXP, as you said before maybe I need install D9 before trying... I will do it later in W7. Smile

Regards

_________________
Siempre aprendiendo

03 Dec 2012, 08:49

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 03 Dec 2012, 15:01

nmake wrote:

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? Smile

(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.

_________________
carpe noctem

03 Dec 2012, 15:01

nmake

Joined: 13 Sep 2012
Posts: 192

nmake 03 Dec 2012, 19:57

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?

03 Dec 2012, 19:57

f0dder

Joined: 19 Feb 2004
Posts: 3175
Location: Denmark

f0dder 04 Dec 2012, 14:38

nmake wrote:

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 Smile

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 Smile

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).

_________________
carpe noctem

04 Dec 2012, 14:38

< Last Thread | Next Thread >

Forum Rules:

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