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

rnlf_in_space

Members
  • Content count

    213
  • Joined

  • Last visited

Community Reputation

1894 Excellent

About rnlf_in_space

  • Rank
    Member
  1. Someone does own the rights. You have to pay them if you want to use their property. What's so difficult about that to understand?
  2. Just wanted to note that I really love the race car driver analogy. I'll steal it from you.
  3. A compiler is not required to provide types of all sizes. The standard says nothing about the availability of certain types. It just defines relationships between built-in types and explicitly makes all the fixed-width integer types optional for exactly that reason.
  4.   That is not entirely true. It's only true when char is 8 bit. There are architectures (that I had the questionable honor of working with) where char was 32 bit and therefore sizeof(uint32_t) == 1. But it's true on all architectures you may encounter in gamedev today. It's just not universally true.
  5. RT @IL0VEthe80s: I had He-Man & my sister had Sindy. Sometimes they'd go on a date. He usually ended up trying to chop her head off ? https…
  6. Your are comparing the iterators while you really want to compare the value of the items in the two lists you are comparing. I would think changing your problematic line to if(*objlist_iter == *iter) should solve the problem. The next problem is that you are trying to erase an object from a list with an iterator of a different list: CObjMgr::GetInstance()->Get_ObjListForKey(tcDelKey)->erase(iter); iter is an iterator of m_ToolObjList. You should CObjMgr::GetInstance()->Get_ObjListForKey(tcDelKey)erase(objlist_iter);
  7. Episode 8 of my Little Big Adventure playthrough on a 486 machine: https://t.co/lTx3yv0lrp #retrogaming #RetroComputing
  8. That really depends on the hardware you are talking about. On old systems, like NES or Sega Genesis, sprites were a hardware thing. The video processor would construct the image by tracing the scanlines of the screen. It had a list in memory that contained the information about all the sprites on the screen (a relatively low number, usually, like 64 on the NES). Then it would scan this list on each scanline to find out which of the sprites are touching this scanline, then load these into some special hardware register and produce the color while moving the cathode ray across the scanline. Sprites were very limited in both dimension, color and total number (per screen AND per scanline: the NES for example only allowed 8 sprites per line, the 9th would be invisible). Usually sprites had one or two possible sizes, could not be rotated or scaled (sometimes they could be flipped vertically or horizontally though, for example on the NES). Later, framebuffers were "invented" or rather became usable for mainstream games. Here, the whole image is constructed in memory before it is being sent to the monitor. The basic principle is the same: The graphics processor would read the memory for the current pixel location on screen and output the signal needed to produce the right color. With this, it became the job of the programmer to define what a sprite really is and what you could do with it. In the early days, these sprites were just "blitted" onto the background by copying memory around. That meant, they usually didn't support scaling or rotation either. This is mostly due to all the calculations being done on the CPU (the mixing, blending, scaling, or whatever effects you allowed on your sprites). As CPUs became faster, people started adding more features, like rotation, scaling, transparency and all that nice stuff. Then, GPUs happened. These are good at drawing textures triangles, and as it turns out, you can represent almost everything you did with the old sprite systems by just creating two textured triangles. So instead of writing the sprite functions to do all the memory operations themselves, people wrote them such that the GPU did the job for them. The basic principle is still the same though: In the end, you fill a big memory area with the byte representations of the pixels. On today's games we see mostly the last two options: Either you use software blitting routines or you let the GPU fill the memory for you. In GL 3.3, you just create a texture, upload your sprite data to it, then you create a vertex buffer containing the corners of your sprite and the UV coordinates (which tell your shader how to attach the texture to the triangles), a vertex array where you define the layout of your vertex buffer (i.e. where in the data can it find the world location of the sprites' corners and where to find the UV coordinates), then you create a fragment and vertex shader (which are probably exactly what you'd find when searching for some basic textured shader tutorials). Once you've uploaded all this data to GL, you can draw. It's a bit much to explain all that here, but every beginner level GL 3.3 core tutorial should cover these topics. I hope this helps!
  9. Little Big Adventure on a real 80486! Let's Play Episode 4: https://t.co/UCzjbfi6Fs #retrogaming #retrocomputing
  10. My new 286 has a map programm installed. It doesn't seem to be quite up to date, though. #RetroComputing https://t.co/XIp5IJ5uUl
  11. Sure. If you know the points before and after the transform, you can just multiply them with the projection matrix, apply perspective division if needed and then subtract the old point from the new point to get the displacement in the image plane.   The interesting part will be to find a transformation matrix that performs these transformations in the image plane. I have no knowledge about that through :)
  12. Episode 2 of my Little Big Adventure Let's Play: https://t.co/GOtTNsEgy3 played on my Am486DX2-80! #retrogaming #dosgames
  13. RT @Sosowski: I don't think I should have woke it up. https://t.co/FzzNjMgbBi