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

bosjoh

Direct vram access in DX

10 posts in this topic

Hm!

Not quite sure what you're asking, so if this reply sounds weird, I probably misunderstood something, anywayz:

Reg. Lock/Unlock. The general rule is that you can't use blit on a locked surface. If your source surface is never changed, you can lock it, get a memory pointer and then unlock it, but continue to use the memory pointer (I don't know if this is legal, but I seem to get away with it ). Locking one surface should not prevent blitting to/from other surfaces.

Reg. different size front and backbuffers: I assume the reason you're talking front and back buffer is that you intend to use flip() in which case different size buffers doesn't make much sense. There's nothing stopping you from creating an offscreen surface with a different size than your primary surface (In either V-Mem or sysmem)...

0

Share this post


Link to post
Share on other sites
The rectangles weren't displayed right. The reason I want to do this is that I don't want to lock the primary surface memory all the time when the program runs (players can't use CTRL+ALT+DEL this way).

The reason that I want to have a bigger back surface is this: I will use a tile based system. This way I have to place all 32x32 (or 40x40) pixel sprites each frame (one layer). But why the bigger surface you may ask.
Well I want to do some scrolling. When you place the sprites on the screen there are 'half' sprites shown on the edges of the screen (when the screen scrolls). I don't want to put pixels out of the screen boundaries. Then I want to flip the backbuffer to the primary surface (/w hardware acceleration).

0

Share this post


Link to post
Share on other sites
doesn't the ALLOWREBOOT coop level flag allow for ctrl+alt+del, or is that just in certain situations?

------------------
--Orion McClelland

0

Share this post


Link to post
Share on other sites
I believe in this circumstance that Lock()ing the surface will grab the Win16 lock and thus really mess up normal machine operation while the surface is locked. I KNOW you can't debug when the Win16 lock has been taken.

As for your problem with using a bigger back buffer, I do not believe a back buffer can have different dimensions than the front. However, let me say that for smooth scrolling (which is what you seem to want to do), you should have a larger offscreen surface where you blit your tiles and stuff, then from that you should blit to the back buffer, then flip. Either that or blit partial tiles to the borders of the back buffer, then normal blit the rest. Either way should get you the effect you want.

- Splat

0

Share this post


Link to post
Share on other sites
Oh yeah.

Niels: Keeping that pointer to video memory after Unlock()ing it is a "Bad Thing." Just think, the video card could decide to optimize its memory and rearrange the blocks of memory. Or you could be accessing memory that was being Blit()ed to and get unexpected results. Etc. I realize that dealing with debugging with DirectDraw is difficult when using your own blitting routines, so maybe you should only use Unlock()ed pointers in debug mode and turn them off when you want to compile a release version of your game.

- Splat

0

Share this post


Link to post
Share on other sites
I can use system memory as an offscreen surface (which will be bigger) and pass it to the primary surface.
But I thought that if I could make the attached backbuffer larger I could get a speed increase (using hardware acceleration). But I guess I have to do it with system memory.
0

Share this post


Link to post
Share on other sites
I think the answer is simple. Instead of making a bigger back surface, simply clip your tiles when you draw them. A good clipping routine will likely be faster than sending all that unnecessary data to the video card anyway.

Regards

Starwynd

0

Share this post


Link to post
Share on other sites
That's the catch!
It CAN be faster to send the extra data using assembler (using 32 bits memcopying). I don't have to use color keying 'cause it's the base layer.
These compares take a lot more clockticks than moves.
0

Share this post


Link to post
Share on other sites
I think the speed difference between clipping the edges and copying the entire tile is pretty minor, and could swing either way (faster or slower) depending on how much is clipped. But since it sounds like your image will be aligned, and is small and 8bit, you're probably right.

However, you're still missing out on a much bigger speed increase. If you threw away your big surface approach, and DID clip the edges, then you'd be able to keep all the surfaces in vid mem, use hardware blitting to copy tiles to the back page (which will be much faster than drawing to your system surface), and then just flip video pages instead of copying your sys surface to the video card, which is generally VERY costly.

Rock

0

Share this post


Link to post
Share on other sites
I know how to lock the surface memory and access the video memory directly. Now I need to know is if you can get a pointer to the attached backbuffer. This way I don't have to lock/unlock again (I can use blit right?).

Now the next question:
I have a 640x480 screen (let's keep it simple: 256 colors). Can I make the backbuffer bigger, let's see 680,520? Then it would look like this:
_____________
| _______ |
| | | |
| |_____| |
|___________|

The big rectangle is the backbuffer and the little one is the screen. Can you use blit to copy only the part that's in the screen to the primary surface?

0

Share this post


Link to post
Share on other sites
I was thinking...
Vertical clipping can be faster (because I can still use 32 bits memcopy) but horizontal clipping can be a pain in the neck (checking if clipped number is divide-able by 4 etc...) however in 32 bits color this wouldn't apply.

I still have much to learn about DX.

0

Share this post


Link to post
Share on other sites