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

Mike

Is there anyone out there that can actually help me?

2 posts in this topic

Mike,

I am looking at your code... it seems that your not taking into account the fact that in 16 bit modes, the pixel format can be several formats, the most common being 555 and 565, plus the layout in memory is different for different cards. This is why people have suggested using blt because it automatically take care of the pixel format conversion for you. Plus, if your surface is in vidram, any hardware acceleration that is present.

If you want to write to the buffer yourself, you have to find out the surface pixel format and use this info when you write the pixel data to the surface. Also you have to take in consideration the surface layout, it is going to be different from card to card. When you lock a surface you get the pitch of that surface which is how may pixels you have to move to get to the next line.

I sent to your e-mail address my ddutils file that has stuff for working with 16 bit surfaces, finding the pixel format, fades/cross fades and so forth.

Let me know if you have any questions about it. E-mail me. jdsgames@jdsgames.com or jdsgames@netzero.net

------------------
Jarrod Davis

0

Share this post


Link to post
Share on other sites
When I tried to run the program on my machine, I get a kinda greenish screen and the graphics are all whacked as far as colors are concerned. I don't see any jumping of the graphics when moving them back and forth, however. I don't have time to look at the source code right now, but I'll take a look later ...

(Why bother using DX if you're going to write your own blit routines? I could understand if they were special alpha blits or other special effects blits, but just a std blit? why handicap your program on MOST machines? the DX HEL isn't THAT bad ...)

-- Pryankster

0

Share this post


Link to post
Share on other sites
I’ve been trying to figure out a problem that I’ve been having with my current 2D engine, and I simply cannot find the problem with my code. I’m not saying my code is perfect, I know something is wrong, I just don’t know what it is.

In my frustration, I’ve made post on this message board before. However, no one is ever willing to really help me out. I get plenty of replies like “I looks like maybe…”, or “Sounds to me like…”, but no one will look at my code and actually help me find the problem. Please do not reply to this post with thinks like “maybe it’s…”. Just reply to this post or E-mail me if you’ve downloaded my source code, run the program, seen the problem, and hopefully found the fault in my code.

I’m not asking for to much here. My code is object oriented (meaning I use classes), and all of the DirectX code can be found in the DirectX manager .CPP file. More specifically, the code to flip the back buffer and the primary surface can be found in the flip surfaces function, and the direct draw setup can be found in the setup direct draw function. Although not extensively commented, my code is neet.

Now for the actual problem I’m having with my code. When the game is run, as the fighters move across the screen, they appear to be shaking very fast (you quickly see what I mean if your download and run the game). I’ve tested to see if for some reason the fighter’s x position is randomly increasing and decreasing as you move left (or right), but it does not. I’ve now spent two weeks on the problem and I cannot find the source of the flaw.

I’ve programmed the game using Visual C++ 6.0, and DirectX 6.0. I use only two direct draw surfaces, the primary surface, and the back buffer. To store all of my images I use arrays of unsigned short (it is a 16 Bit game, full screen). I’m trying to write a software only engine, and I want to code my own drawing routines and the like. Thusly, please do not reply with ideas like “Just use BltFast”, or “Use the hardware”.

I hope someone can actually help me, and not just guess at the problem.

You can download the source code and needed animation files from the following location: http://mike010.hypermart.net/source.zip . Please note that if you wish to debug the game, you can change it to a windowed mode application by change the true to a false on line 190 of the win_main.cpp file.

0

Share this post


Link to post
Share on other sites