• 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

4347 Excellent

About Nik02

  • Rank
  1. It is possible to read the contents of RAM chips from a live machine too, if you have physical access to the memory bus lanes (and this is not as difficult as it may seem). While disabling the page file is a small hindrance to an attacker, it is not a very robust method on its own. If an attacker has physical access to the machine, be it powered on or not, he/she/it can bypass any protection implemented on that machine.
  2. Does the game logic evaluate the slot or the position when determining object location?
  3. Both the address and the data values are simply arrays of bits on the buses, that can be read by anything connected to said buses. When the cpu wants to write some value x to address y, it sets the data bus bits to represent data x, and the address bus bits to represent the address y. When the rom selector circuit sees the value of 0xff50 on the address bus, it knows that the value of the data bus has the meaning of the desired ROM source and sets the cs1 and cs2 lines accordingly to actually enable the correct ROM.
  4. "writing $1 to $FF50 disabled the boot rom​" would imply that my logic above would be somewhat correct. The "memory selector circuit" would likely be the place where the reaction to the bit at FF50 would be implemented :) if (address == 0xff50) {cs1 = !data; cs2 = data;} Where address and data are the current contents of the address and data bus, respectively.
  5. If a specification says that FF50 controls the ROM chip select bit, I would assume that it works somewhat as follows: CS1 = NOT (FF50 bit 0) CS2 = FF50 bit 0 But I'm not a GB hardware expert nor have I read the specs, so I can't verify this off the top of my head.
  6. I believe that the signal CS1 sets the "read enable" bit of the internal ROM chip, and CS2 sets the equivalent bit on the cartridge ROM. As these are on the same bus, the memory reads would simply be served by the chip that is activated for reading at any given time.
  7. On all c-style languages, the return statement exits the current function scope. You may mistake the console lifetime for the program lifetime.
  8. The problems discussed in this thread are related to the architecture of your application; changing the server type or the programming language does not fix the issues. Security is not very easy, but it is very necessary.
  9. I'm surprised if Unity doesn't support floating-point textures, as Unreal certainly does. Then again, some mobile devices and old GPUs may not have support for them, so Unity may simply cater for a lower common denominator. With floating-point images, it is perfectly viable (and common) to store values beyond 0...1 range; for example, the immediate vicinity of the sun is physically several orders of magnitude brighter than the rest of the sky, and the image could still preserve the brightness dynamic (as in high dynamic range) of both the sky and the sun so as to preserve the details for every area of the image without "burning through". HDR is very useful as input for physically-based lighting. Though the results need to be tone-mapped for the display device (scaling the values to a practical displayable range), HDR often enables very realistic lighting that works with both dark and bright scenes.
  10. Recent versions of Photoshop can handle 32-bit per channel floating point images.
  11. Also, if you want to run this type of functionality in the background without having any client calling the script, consider setting up a cron job (on Linux) or a scheduled task (on Windows) that calls the stuff you want to run periodically.
  12. The problem is that an attacker could call the soma.php script directly with arbitrary values for c. I am not able to answer whether or not this is actually a valid use case in your application, but in general you don't want the client to be able to specify any values written to your database directly. You likely want to apply at least some kind of sanity checking in order to make sure that the user input is making sense in your application. Just because you don't have a visible link to said script, doesn't mean that the attacker could not call it. He/she can simply observe what the client-side script does, and/or inspect the traffic between the browser and the server.
  13. VS3 does not support integer operations natively. Some ops can be emulated using floating point math (and the HLSL compiler will strive to do this automatically when it can), but bitwise operations won't generally work.   In order to reduce apparent visual repeating of the textures, you should use sufficiently large prime numbers as scale factors of the different layers. This is based on the fact that any given prime is divisible by only 1 and itself; thus, 2 primes as scale factors will never reach the same texture coordinate at any integer interval, except at the origin. If you choose to use this strategy, pick a prime like 29 (not too small, not too large), take the next primes so that the next one is approximately 1.3 to 1.7 times the last one (the precise numbers are not important), and follow this for each additional scale factor you need.
  14. Also, consider that an attacker can call the soma.php script as many times as he/she/it likes, with a variety of valid values for "c" that would not get caught as a sql injection. Therefore, an attacker could arbitrarily increase or decrease the "gold" of your "cities". Maybe this is your intention, but I would implement some kind of sanity checking here.   It is not wise to trust the client at all. 
  15. Good In addition, if "ouro" is a number (I assume it means "gold"), you can cast it to an integer or a floating-point number before inserting it to the query. This way, you eliminate the chance of it being an arbitrary string.