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

AAAP

Members
  • Content count

    243
  • Joined

  • Last visited

Community Reputation

137 Neutral

About AAAP

  • Rank
    Member
  1. Hmmm, that may be the way I'll go then. But the textures in D3D are in DDS format as well right? So that still leaves me a bit stuck. ah well :x
  2. in the load struct the data is in RGBA, however in following one of the articles on GD.net, I save the num bits and the low bit for each element of the pixel one time during initialization of primary surface. Now this rides on the assumption that all surfaces have the same pixel format, which would make sense of course but I don't know this to be true for sure. At any rate, it is really making me feel dumb lol. By incorrect colours, what I mean is the whole screen is tinted blue with black vertical scanlines (I guess those are due to the alpha channel or something not cooperating with the pixel format ) Also, when I try doing a memset, what I get is a correctly colored image that takes up about 12/th of the surface ( which is actually only about a third of the full sized image ), and repeats it several times. I tell you, things were much simpler with openGL to do this kind of work for ya lol but hey it's a good learning experience I guess. I can't wait to be doing sprite rotations and scaling if this is giving me so much trouble :p
  3. hmmm... i tried your advice and, while it does not segfault, it again seems to use the incorrect colours. I know I'm doing something wrong thats really obvious, I just don't see it.
  4. Thanks.. Now I can grasp this.. I just want to know this one thing, because this is what I had come to understand from reading I did. 1) The surface should have the same number of elements as the display mode ( EG, RGB for 24 bit display, RGBA for 32 bit display? ) 2) (and I'm not 100% on this one) all surfaces created under a IDirectDraw interface should be in the same pixel format. As demonstrated in that one tutorial paper on GD.net on putting pixels into a DDS, I call getpixelformat after creating the primary surface, and save the bits and low bit as global variables. So this is not enough, I'm guessing? Also, about the "squashing data into 8 bits" thing, I was getting segfaults when using shorts or longs instead of chars, which just baffled me. The pixel format for my primary surface is 32 bits, 8888 (where only 1 bit of the alpha is being used), and if the above are true then all surfaces should be like that. I guess I just got a bit flustered and started trying different things instead of rationally thinking about it, but it still confuses me why I would get a segfault doing that. *Tears hair out*
  5. set the pixel format? i was under the impression that the pixel format for a surface is the same format of the current video mode o_o can someone please elaborate on this?
  6. It's been a long time since I've posted to GD.net, and I feel that I've developed a lot as a programmer... HOWEVER, I've been trying to extend my 2D engine to work with directdraw as well as openGL, and I'm running into some issues. Now, the problem is really just loading graphics onto a DDS... Before I had known about the lPitch variable, it seemed like I was able to load the full graphic onto the surface, except it would be tinted with the first color of the RGBA int, so everything would be tinted red for example. After reading up a bit more, I would get the right colors... but something horrible!! It only seemed to fill about 1/4 of the surface!! as demonstrated here... It really baffles me, I don't understand why. So I was hoping someone with more DirectDraw experience could shed some light on this for me, I would be most grateful. PS Yes i have read the articles on loading images in DDraw and what not, I found them very informative, but rereading them again and again havn't been much help to me on this. Here is my "loading image into DDS" code, currently : int img_to_dds ( struct s_imgload *load, struct s_image *img ) { DDSURFACEDESC ddsd; int i = 0; int x, y, p; int pixels, px; //DATA8 *pixelptr; //DATA32 *pixel; DATA8 *pixel; unsigned int *lpscreen; memset( &ddsd, 0, sizeof(ddsd) ); ddsd.dwSize = sizeof(ddsd); ddsd.dwFlags = DDSD_CAPS | DDSD_HEIGHT |DDSD_WIDTH; ddsd.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN|DDSCAPS_VIDEOMEMORY; ddsd.dwWidth = load->w; ddsd.dwHeight = load->h; if (IDirectDraw_CreateSurface( DDRAW, &ddsd, &img->surface, NULL) != DD_OK) return FALSE; IDirectDrawSurface_Lock( img->surface, NULL, &ddsd, NULL, NULL ); pixel = (DATA8 *)ddsd.lpSurface; p = ddsd.lPitch ; pixels = load->w * load->h; for ( y=0;y<load->h;y++ ) for ( x=0;x<load->w;x++, i++ ) { int c; int r,g,b,a,cr,cb,cg,ca, rgb; rgb = 255; c = (DATA32)load->data[i]; READ_RGBA( &c, cr, cg, cb, ca ); //pixel = x+y * p; r = ( cr * ( 1 << r_bits )) / 256; g = ( cg * ( 1 << g_bits )) / 256; b = ( cb * ( 1 << b_bits )) / 256; a = ( ca * ( 1 << a_bits )) / 256; // Convert the Values to the appropriate Location in the returned colour value r <<= r_low; g <<= g_low; b <<= b_low; a <<= a_low; rgb = r | g | b | a; //pixel[x + y] = rgb; pixel[x+y*p] = rgb; //pixel[x+y*p] = 255; //memset ( pixel, rgb, 4 ); } IDirectDrawSurface_Unlock ( img->surface, NULL ); return TRUE; } In the above, the imgload struct is just a struct with the height and width of the image, the BPP and a pointer to the data, it gets filled by functions which are modified from imlib2, and work reliably in OpenGL, so I'm not convinced that the problem is in that area. Thanks in advance for helping.
  7. H'okay, generally I was using openGL for 2D and 3D graphics, so I thought I'd diversify a bit and give DDraw a shot. Now, I've gotten this far: I have fully initialized everything, and have a working double buffer between my front n back surfaces. When I try to use other surfaces though, there are some issues. When I started, my goal was to make a smaller test surface and fill it blue, while the background was filled black. Simple enough, but when I do a colour fill on my test surface, it fills the entire front surface. That sucks!! Also, I found that when I attempt to use the DD7::BltFast function, I get a segfault. So I thought maybe my surface wasn't created properly. Anyway, here's some code. Gimme a hand please O_o Sprite::Sprite(AppWindow * win, int X,int Y,int W,int H) { window = win; x = X; y = Y; width = W; height = H; DDSURFACEDESC2 ddsd; ZeroMemory(&ddsd, sizeof(ddsd)); ddsd.dwFlags = DDSD_CAPS | DDSD_HEIGHT | DDSD_WIDTH; ddsd.ddsCaps.dwCaps = DDSCAPS_OFFSCREENPLAIN; ddsd.dwHeight = width; ddsd.dwWidth = height; lpDD->CreateSurface( &ddsd, &surface, NULL ); } Sprite::~Sprite() { } void Sprite::_Draw() { HRESULT ddrval = DD_OK; //ddrval = lpDDSBack->BltFast( x, y, surface, NULL, // DDBLTFAST_NOCOLORKEY | DDBLTFAST_WAIT); DDPIXELFORMAT ddpf; ddpf.dwSize = sizeof(ddpf); DDBLTFX ddbltfx; ddbltfx.dwSize = sizeof(ddbltfx); ddbltfx.dwFillColor = 0; // Pure blue RECT r, r2; r.left = 0; r.top = 0; r.right = 640; r.bottom = 480; //lpDDSBack->Blt(&r2, NULL, &r2, DDBLT_COLORFILL, &ddbltfx); ddrval = lpDDSBack->Blt(&r,surface, 0, DDBLTFAST_NOCOLORKEY | DDBLTFAST_WAIT, 0); if ( ddrval != DD_OK ) { //lpDD->Release(); } //ddrval = lpDDSOffscreen->Blt(NULL, surface, NULL, DDBLTFAST_WAIT, &ddbltfx); //ddrval = lpDDSBack->Blt(NULL, surface, NULL, DDBLT_COLORFILL, &ddbltfx); //lpDDSPrimary->Flip(surface, NULL); //if(ddrval != DD_OK) //return; } Things are commented/uncommented in various places as I was testing different things to try and figure out what was going on, so it's a little messy. Anyhow, I'm sure someone's dealt with this before. My Direct X SDK version is (December 2005), if that has anything to do with this.
  8. Well, I'm just settling for making everything use the same parameters (for commands at least), I guess it's not a big deal.
  9. can T be in the form of a whole function prototype such as the return type and parameters? sorry for the newb questions, but this whole topic seems a little over my head at the moment.
  10. well with visual C++ it's easy to choose release mode and have all debug info stripped from executable, resulting in much smaller file. I'm not exactly sure of the parameters in GCC, but I don't believe it has to do with compression, thats more of an optomization thing. If you're using Dev-C++, you can go into project options -> compiler -> linker and set Strip Executable to yes (it seems to be "No" by default), I would bet that would solve your problem. I don't know the actual gcc command line switch for this however.
  11. Huey, nice 8) and I doubt that its stripped of debug info and such... are you by any chance using gcc?
  12. I thought boost::function was a implementation of functor?
  13. Hey, I took your advice and started switch to just using the boost function ptrs and bind system. I used http://www.codeproject.com/library/BoostBindFunction.asp website as a base. Now, i see that you need to make different function templates for different varieties of variables... so this puts me in the same situation that i was in before, essentially. theres only room for one "kind of function" in the command container. Any tips?
  14. I posted about this in the Game Programming forum, but maybe it's more appropriate here.. and I will elaborate on the question: Using the command pattern with function pointers (instea dof writing new Execute method for command classes, use single class per reciever and point the execute method to desired function), i get decent usable functionality. However, I can only make calls to functions with no arguments (Because of "typedef void (Game::* Action)();", which is set for no arguments!!) My solution was to make another subclass of Command class, with Action typedefed with an argument.. So I had to prototype new Execute method in Command, and make it do nothing in other subclass, of course. Anyway, it seemed like this should work for me, but when I tried to run it it gives message "illegal call of non-static member function" because of this line: boost::shared_ptr<Command> cmd(new StringCommand(&game, &Game::OpenMenu(file))); StringCommand is the subclass of Command that should accept 1 std string as argument. Am I just trying to send address of function+argument to the StringCommand object wrong, or is this just impossible to work anyway? If any other code is needed, id be happy to post some.
  15. UPDATE: Heh, I've gone with the command pattern and have a largely operational system now. Only problem is, my commands allhave to have the same arguments. That's not very useful to me. This is the solutions i came up with: -Use type unsafe varargs (if thats even possible with function pointers?) -Make prototypes of execute function with different varieties of arguments (Tried this but it didn't seem to work !? I thought it was a good bet) short of this, I'm at a loss. But I'm sure it's doable... Blar.