Check out the article on fused bitmaps. It explains the idea in way more detail than I explained it. Just go to my website. Click here to visit my website.

Correct me if i''m wrong, but how is this different from a normal backbuffer? More to the point, why do you think doing this manually is going to be better than "messing around with the display device"? From the sounds of it, you havn''t actually tried benchmarking this against a ''normal'' drawing method, otherwise I think you''d see that its going to be slower than using hardware assisted blits.

quote:Original post by OrangyTang
Correct me if i''m wrong, but how is this different from a normal backbuffer? More to the point, why do you think doing this manually is going to be better than "messing around with the display device"? From the sounds of it, you havn''t actually tried benchmarking this against a ''normal'' drawing method, otherwise I think you''d see that its going to be slower than using hardware assisted blits.

This would be a quicker method because you''ll only be doing one blit and not maybe 20. And in this method you don''t use memcpy() or other windows memory copying routines because they do a lot of overhead checking. I write my own memory copying routines. Maybe this is like back-buffering in a way but it just happens to be a lot quicker!

your webpage has sound. i hate pages with sound. i''m listening to music and i do analoge records of music while browsing web. i don''t want to restart that stuff just because of your f***ing webpage.

for the rest.. i don''t see anything useful in it yet.. i''ll read it more carefully again..

"take a look around" - limp bizkit
www.google.com

how old are 2d graphics now? 10years? 20 years? 1000years?

don''t you think people know yet that you can simply do memcopies for data with the same format? and don''t you think they copy per scanline yet? you describe a simple blit into a bigger texture/bitmap, exactly how it is done with the functions f.e. the win32api does provide.

and you know what? dx even uses _HARDWARE_blitters, if available!! those are up to 100 times faster than your code will ever be.

and you use mmx/3dnow/sse/sse2 code for fast memcopies?

"take a look around" - limp bizkit
www.google.com

quote:Original post by davepermen
how old are 2d graphics now? 10years? 20 years? 1000years?

don''t you think people know yet that you can simply do memcopies for data with the same format? and don''t you think they copy per scanline yet? you describe a simple blit into a bigger texture/bitmap, exactly how it is done with the functions f.e. the win32api does provide.

and you know what? dx even uses _HARDWARE_blitters, if available!! those are up to 100 times faster than your code will ever be.

and you use mmx/3dnow/sse/sse2 code for fast memcopies?

"take a look around" - limp bizkit
www.google.com

Interesting... but I will not take the music off my page, sorry. And lighten up a little you don''t have to be so harsh about my article I''m just trying to improve my games by finding out about stuff on my own.

thats both no problem.
you just have to accept two facts:
i will never visit your page anymore (i don''t think that bothers you. but it does bother me, as i would like to read your stuff)
never ever think you found out something new. most "new" stuff of today is between 20 and 4000 years old fact.. :D still, its worth to re-invent stuff, you learn best from it. and it certainly is good to learn how to draw stuff on your own. just don''t get dissapointed if you don''t get speed boosts, because you can''t design hw to do the job for you, and you don''t know (at least, normally you don''t know, and me neighter) hw that good as driver developers do. so you can expect them to implement the stuff about the fastest way possible..

still, good luck. i remember my first handfilled triangles.. heh.. those where the days:D

i did not planned to sound harsh. but i know i often do nontheless. sorry for this:D

"take a look around" - limp bizkit
www.google.com

I am not quite sure I understand what your are doing and how it differs from standard surface to surface blitting (as part of double buffering)...

You say "The code of the master bitmap serves as a "map" for the other bitmaps". How does it serve as a map? Do the colors of the other bitmaps get mapped (ie stored) on this bitmap?

quote:"To map another bitmap to the master bitmap you would need to first locate the scan line you want to be in (Y-coordinate) and the 3 byte triplet you want to start mapping the bitmap over (X-coordinate). Now all you have to do is start copying the bits from the other bitmap's buffer and copy them scanline by scanline. For instance if the bitmap is 3 pixels high you would start at your Y-coordinate and increment the Y-coordinate until you have copied 3 scanlines. That's how bitmap fusing is done! "

How does that differ from a standard surface to suface blit? A software blitter would do those exact steps (with a couple of optimizations to reach the next scanline). Using the slow memcpy as you put it (Which isnt That slow btw!) and ignoring clipping (unless you are using huge guard bands) and few other things (this is just off the top of my head, and it is late), your code would do something like this

     for ( row = y; row < (y + srcHeight); row++ )       memcpy( &masterBitmap[row*masterWidth + x], &srcBitmap[(row-y)*srcWidth], srcWidth*3 );     

Where y = your startY , x = start x (into the row). This about right?

Anyways, in the end you have one large Master Bitmap containing the fused chunks of the other smaller bitmaps right? Then you just draw this big huge buffer in one call, thus saving the overhead of calling blit for every bitmap in your scene right?

Unless I am missing something, you need to do a little more research on double buffering (back buffering) as that is exactly what it does....




[edited by - Entz on December 9, 2002 6:51:44 PM]

You're basically doing blitting in software, which is actually how computer graphics started out. The vast majority of the old DOS games worked that way, but thanks to hardware acceleration, large amounts of video memory, etc. that method has been improved upon, so if I were to write a 2D game today, I would in fact implement a similar technique as fallback for people who have crap graphics cards but utilize the hardware if possible.
I don't quite see your problem with memcopy though. It's not like they purposely implemented memcopy to be slow just to annoy people, it actually *is* fast, although you can probably improve upon it with processor-specific calls.
Oh and forcing people to mute their soundcard when they visit your page is rather rude. Your site doesn't work on Opera either, you'd better fix that.

- JQ
Full Speed Games. Are back.

[edited by - JonnyQuest on December 9, 2002 8:55:24 AM]