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


  • Content count

  • Joined

  • Last visited

Community Reputation

154 Neutral

About marsong

  • Rank
  1. [quote name='PhantomRonin' timestamp='1342809099' post='4961401'] Yea I was thinking of doing this but if I wanted more then one torch I would have trouble [/quote] You could implent a basic lightmap: Setup an array as big as your screen: uint8_t lightmap[SCREEN_SIZE]; - Reset lightmap to 0 (black) - Do one pass and fill this lightmap, you would basically take your lightsources, fill in whites in your lightmap at their position (use some fade out formula so it gets darker further away from the light source) - Alpha blend (multiplicative blend) the screen with your lightmap Although, doing this in software is gonna be pretty slow if you use a high resolution.
  2. Use two input buffers, that way you can keep track of key presses and releases. I use something like this: [code] static char key_state[2][NUM_KEYS]; static int curinput = 0; // this is called every frame void update_input(void) { curinput ^= 1; // flip to next buffer index memset(key_sate[curinput], 0, NUM_KEYS); // clear it // now process all the input events and populate // our key_state buffer, do it in your WndProc, your event loop, // sdl, or whatever // i use sdl, but translate into my own key codes Uint8 *state = SDL_GetKeyboardState(&n); translate_sdlkeys(key_state[curinput], state, n); } // now you can query these two states for key presses and releases like so: // is_key_press: // key is down this frame AND was not down last frame key_state[curinput][key] && !key_state[curinput^1][key]; // is_key_release: // key is up this frame AND was down last frame !key_state[curinput][key] && key_state[curinput^1][key]; // if you just wanna know if the key is up or down, just query the current state key_state[curinput][key] // 1 on down, 0 on up [/code] Obviously wrap that up in functions or your input class, but that is the gist of it.
  3. [quote name='lonewolff' timestamp='1326401492' post='4902102'] This is fine for a 4:3 ratio screen but if you if you do this on a 16:9 screen, guess what? It gets stretched out. Thats why I go for the users native resoultion. and position things relative (not absolute). From my understanding, this is what the AAA game dev's do. [/quote] But the thing about 2D games is that changing the screen resolution can significantly change the gameplay or feel of the game because of how they usually use planar coordinates. Diablo 2 widescreen "hack" is a good example of this, the oringinal game has quite a narrow view to limit your visibility for monsters, but using the widescreen hack you gain a huge view of the surrounding area and get quite a different experience of the game. In 3D games this effect isn't felt that much because most of the action takes place along the z-axis ("dow/ninto" the monitor)
  4. Just store the last time the cursor moved, and if the current time minus the last time is greater than some threshold then move again. [code] struct cursor { float x, y; int last_tick; }; cursor c; cur_tick = get_current_time_in_ms(); if (key up pressed && key is repeated) { // can't remember how you check this in SDL, think there's some flag or something in the keyevent that tells you if it's a repeated key (key being held down) if ((cur_tick - c.last_tick) >= 1000) { // if you hold down the up key, the cursor will take 1 second (1000 ms) to move to the next stop move cursor up; c.last_tick = cur_tick; // update the time it last moved } } else if (key up pressed && not repeated) { // just move without checking time, but still update last_tick move cursor up; c.last_tick = cur_tick; } [/code]
  5. Quote:Original post by mind_wipe I though that tv.tv_nsec records nano time so doesn't that mean you have to divide by 1000 to get milliseconds? No, you have to divide by a million. Also, you're not using the tv_sec field, you should do this: tv.tv_sec*1000 + tv.tv_nsec/1000000 to get milliseconds. Your other function should just be: return G_GetTime() - st_time; if you want it to return the difference from now to when you called G_SetState.
  6. Quote:Original post by mhagain Have a look here: http://www.gamedev.net/community/forums/topic.asp?topic_id=339475 Apparently SDL_GetTicks is a no-go area on Windows. Might be better off #ifdef'ing it out and using timeGetTime instead (don't forget to use timeBeginPeriod (1) first). SDL_GetTicks uses timeGetTime on Windows, and it sets timeBeginPeriod to 1 (although it depends on how you compile SDL, it has a USE_GETTICKCOUNT macro definition it checks for).
  7. LARGE_INTEGER is a 64bit integer, there's no chance it will overflow from running too long, it will take years to overflow. [Edited by - marsong on August 10, 2010 1:26:49 PM]
  8. Quote:Original post by gretty Thanks for the replies guys :D Thats sounds reassuring, I'm going to get windows 7 64bit. @twf; Why dont some of those win32 programs work on an 64bit OS? It doesn't have anything to do with using the win32 GDI objects I hope, or do they use some obselete win32 functions or something? I doubt there are "a lot of games" that don't run under 64bit, they would have to be using some draconian DRM that requires some device driver/code injection/etc that isn't available for 64bit versions, or they are actually old 16bit programs (so not actually 32bit) which don't run under 64bit because it dropped support for it.
  9. From the sscanf reference: Non-whitespace character, except percentage signs (%): Any character that is not either a whitespace character (blank, newline or tab) or part of a format specifier (which begin with a % character) causes the function to read the next character from str, compare it to this non-whitespace character and if it matches, it is discarded and the function continues with the next character of format and str. If the character does not match, the function fails and returns. So it doesn't quite work like you want it to. It will read the first quote, discard it, continue reading the %s and that will continue until it finds a whitespace, so it will go ahead and include the ending quote in the string (a is now test"), then the position is at the whitespace in the format string, so it will compare your second quote with whitespace, see that they don't match and fail (not null terminating a or b). You're gonna have to write some custom string matching function or use some regexp library.
  10. Inline assembly is generally a bad idea because it can mess with the optimizer, you should either write the entire routine in assembly, or use compiler intrinsics. In this case since it's a class, you should probably go with the compiler intrinsic, because if you want the class methods inlined you would have to write the entire class in assembly (because I don't think msvc can inline functions in object files that has been generated separately by an assembler).
  11. Quote:Original post by Washu That's a bad idea, mainly because localization will completely break that. The proper way to do it would be to use SHGetFolderPath (SHGetKnownFolderPath on vista, but SHGetFolderPath wraps that) and specify CSIDL_APPDATA for the path you wish to request. You can use CSIDL_COMMON_APPDATA for data that the application requires that is non-user specific. CSIDL_LOCAL_APPDATA is the best one to use though if your application might be run on roaming clients and your data does not need to roam (otherwise the data bloats the roaming profile). %APPDATA% does not break localization, it returns the correct path to C:\Users\<username>\AppData\Roaming (for Vista/7, or whatever the localized path is on Windows XP). You might be thinking about using %USERPROFILE% and appending Application Data (or similar), which would break localization.
  12. getenv("APPDATA") gives you the path to a directory where user-run programs can read/write to files. You should create a directory in APPDATA (probably the program's name), then you use APPDATA/name to store all files the program needs to write to.
  13. I thought malloc was suppose to be an efficient allocation mechanism on top of HeapAlloc, but looking at the crt source code you can see that malloc (and operator new) pretty much just calls HeapAlloc directly, so from a logic standpoint they are effectively the same. (Maybe HeapAlloc already is an optimized memory allocator?)
  14. Setting up the x64 compiler as a custom build tool always works, but that is hardly any better then using the command line. You edit the default property sheet, set up the command line and save it, then you right click on the source files, choose to use custom build tool, and then you can build from the IDE as usual. But you wont get any debug/release options, you would have to manually edit the options for each if you need any extra beside the default options you set in the property sheet.
  15. It's perfectly safe and the preferred way of doing things. <iosfwd> for example forward declares iostreams and the like, so you don't have to include the beast <iostream> if all you wanted was to add support for the << stream operator.