• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.

Archived

This topic is now archived and is closed to further replies.

voodoo

My own blitters continued. And some bench marks.

3 posts in this topic

Your benchmarks are useless without proper experimentation ie results on X number of machines using optimised software and hardware rendering!

I did exstensive research into this area and consider myself as quiet an expert at graphics programming mainly for my ASM experties so as you can guess I have written a few software renderers in my time.

Here is your quote:
"you can't beat the speed of hardware period. Use the blitter."
Very true but what happens if there is no hardware accleration or limited capabilities!!!

Not all graphics cards support all the latest accelerartion techniques even my computer, not even a year old does not support any form of video to system or system to video aceleration!

Now I know that the Microsoft documentation on Direct Draw hardware accleration usage is a little vague in this area so I will try and make things more clear.

DDCAPS_BLT
Hardware blitting supported Video To Video only!!!

DDCAPS_CANBLTSYSMEM
System to Video and Video to System blits using DMA. This may require the use of PageLock and PageUnlock to use the hardware acceleration

DDCAPS2_NOPAGELOCKREQUIRED
if DDCAPS_CANBLTSYSMEM then no page lock is required for hardware acceleration

DDCAPS2_NONLOCALVIDMEM
AGP non local video memory support make sure your surfaces are created using the non local video memory flag when calling CreateSurface. Non local video memory is an area in system ram treated like video ram.

DDCAPS2_NONLOCALVIDMEMCAPS
The blitting capabilities to non local video memory are not the same as video to video check dwNLVBCaps & dwNLVBCaps2

So in conclusion for a well designed game you have to anticipate a veriaty of hardware config's and write a number of update/rendering routines optimised for to use what hardware acceleration is avaliable and there are a hundred ways that can be writen. This can be seen with 3D games when they have different renderers for Glide, OpenGL, D3D, and Software.

Phillip stiby
============================
Technical Manager Coull Ltd.

PS So the better quote to use is

Use hardware were avliable you can't out code it, but if it's not avaliable a piece of well designed personalised code is a lot faster then an all round blitter like IDirectDrawSurface::Blt()!

0

Share this post


Link to post
Share on other sites
Andre Lamothe isn't a famous game programmer, he is a famous game programming book author, there is a distinct difference.

As far as any benchmarks go, they mean nothing really. I don't see your code, so for all I know, it could be written horribly.

Or your structures could be garbage, I can't see any of that.

If you show me one circumstance where a hardware blitter beats a hand written one, I'll show you another in which the opposite is true.

0

Share this post


Link to post
Share on other sites
Alright this post will be stopped before it gets out of hands!

No more bashing each other...

We are all one big familly:P

0

Share this post


Link to post
Share on other sites
At the bottom are some bench marks I did with my own engine...

Guys, I think most of you are complicating your lives for nothing!

Just use the DX blitters! To tell yeah the truth I think DX is the only good thing to come out of MS. Especialy DDraw and D3D.

I say, use the blitters for what ever is supported, Colorkeying, Rotation, Scaling and writte your own stuff for what's not support ed like Alpha blending.

For those who mised out, I e-mailed Andre Lamothe(famous game programming author) and I asked him a simple question...

Should I write my own blitters or should I use the DX blitters, and I even went on to explain to him about the surface locking overhead and the system ram problems...

You know what he told me and I quote
"you can't beat the speed of hardware period. Use the blitter." That's all nothing else just one line reply

Bench marks:

Target computer
- P2 300
- 64 MB
- ATI XPERT@PLAY PCI 4MB

Engine setup
- 16 bit
- 640x480 Res
- Double Buffering

Frame counting system
1- Get current time at top of loop
2- Do all blitting and game logic
3- Increment frame counter
4- Check time if it's past 1 sec display frame rate
(Just to make sure there no cheating going on)

Blitters
- MS DirectX BLT(NO BLTFAST)
- No special written blitters

Situation
All images loaded into system ram.
30 calls to GDI for putting text on screen
1 640x480 image back ground
100 sprites of 120x45 size

Frame result: 22-23 frames a sec
With triple buffering: 28-30 frames a sec.

0

Share this post


Link to post
Share on other sites