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

dave j

Members
  • Content count

    424
  • Joined

  • Last visited

Community Reputation

681 Good

About dave j

  • Rank
    Member
  1. WebGL 2.0 is based on OpenGL ES 3.0, not Vulkan. You can find the WebGL 2.0 draft specification here.
  2. You should have a union of structures not a union of unions. The latter will put all the variables in the sample space.
  3. Kylotan's suggestion of using unions is the way to go. You can see an example of how to use them for the sort of thing you are wanting to do by looking at SDL's event handling - specifically SDL_events.h. Look at the SDL_Event union typedef at line 525.
  4. It is pretty much calculating the shear and scaling of the corner points. It might help to think of what happens to the sprite's bounding box when it's transformed. Below is the sprite transformation animation from the blog with the bounding box of a sprite shown: The steps it shows are: 1. Isometric view on isometric grid. 2. Move bottom right point to match distance (i.e. perspective distorted grid). 3. Scale height to match height of right edge at that distance. 4. Move bottom left point to match distance. 5. Scale height of left edge to match that distance. Note the top and bottom edges are not parallel in step 5. This matches the following image from the blog: Calculating the positon of the bottom right point and the height of the right edge are realtively easy. Calculating the bottom left point will be difficult since you really want to match the position of a point some way above it to a position on the ground. It might be easier to calculate the top left point and left edge height instead. (Adjust as appropriate for right facing walls.) Whilst it might be difficult to implement all this in a shader I wouldn't bother trying, at least until you've got it working on the CPU. Remember, this game was released before GPUs had shaders and CPUs were much slower at the time too. You shouldn't have performance problems doing the maths on the CPU and passing all the quads to the GPU for rendering.
  5. The page on SNES Mode7 he links to early on gives a clue in the section on transformations: They alter the scaling of the sprites depending on how far away from the view point each row appears on screen. Think about drawing the ground tile diamonds. The scale at the nearest point is going to be larger than the scale at the farthest point. Scaled in this way, the quad you use to draw your tile will look more like a trapezium rather than a rectangle. The good news is, if you are using 3D hardware to draw your sprites, you only need to work out the scaling at the corners and the hardware will take care of the rest. The bit about sprite orientation for walls seems to be to allow different hacks depending on whether the left or right of a sprite is nearer the viewer.
  6. It's worthwhile understanding the differences between immediate (usually desktop) and tile based (usually moble) GPUs and how they affect performance. Even if you are only targeting desktop systems, it's still useful because desktop GPUs are beginning to implement some tile features and techniques that work well on tile based GPUs may be able to take advantage of Vulkan's renderpasses.
  7. Miguel Cepero's Procedural World blog has lots of discussion about the technology behind his Voxel Farm product. It might not go into enough detail for you but will provide a jumping off point for further research.
  8. It's the amount of illumination emitted by a light source and is something that you define for each light. It's explained in section 5.2.
  9. I don't get people's hatred of GPL. If you don't like the terms of the licence it's simple - don't use the software. Same as it is with any other software. Comparing it to BSD and other more permissive licences just smacks of whining "They let me use their software as I want without paying, why don't you?". The people making such comments never seem to complain that proprietary software doesn't allow that either.
  10. The proportion of developers producing closed source software is far greater than that producing open source software so it would be strange if that was not the case. Even so, as others have mentioned, open source is all over the place even in commercial products as middleware and embedded stuff.
  11. Pi's are the spiritual successor to the BBC Micro, which had lots of I/O ports, not the Spectrum. You're not the target market for a Pi. Think a 12 year old kid who wants to try programming and has been inspired by seeing some devices people have built with sensors. Her not technically aware parents won't let her plug a circuit she's made into a computer costing a several $100s[1] in case she breaks it but persuading them to let her try it with one costing a few $10s is much more likely. The fact that so many of them have been bought by middle aged men who used Beebs at school just means that the Raspberry Pi Foundation had more money to spend on it's educational initiatives. ;) Pis where originally envisaged to have Python as their main programming language and most of the learning resources created by the Foundation is geared towards that language, with Scratch as an easier introduction for younger kids. For a programming novice, hardware programming on a Pi is easier than on an Arduino because of the development environments available. You can even do GPIO programming in Scratch now too - which has to be the most novice friendly way available. [1] Even if it provided access to GPIO ports - find a desktop or laptop even does that.
  12. It's a bad idea. Think what you will have to do if you want multiple sizes of your model in your scene, you'll have to either: a. Update every vertex of your model and draw from CPU memory or upload it to the GPU every time you want to use it - both of which are slow. b. Keep several copies of your model stored in GPU memory - which isn't inherently slow but you might prefer to use the GPU memory for something else. You could just prescale the x,y,z components in this case as well. It's far better to pass a scale factor into your shader using a separate variable.
  13. Sorry. I didn't realize you wanted to use an already existing device. Your best bet will be to pick a suitable device and see if people have already figured out how to interface to it, it's message formats, etc. Look for ones that have support in Linux - you should be able to look at the driver source code to see how they work.
  14. Your best bet is likely using an Arduino or other microcontroller board to interface with various combinations of accelerometers/gyroscopes/magnetometers. You can get chips that contain various combinations of these sensors on little circuit boards that are easy to connect to an Arduino. By using multiple, different, sensors you can improve the accuracy. Oversampling, i.e. quicker than you need, and filtering the values can smooth the output. Details of connecting position sensors to Arduinos here.
  15. Raspbian is a port of Debian compiled for the processor used in the Raspberry Pi[1] so look for Debian documentation. A good place to start id the Debian documentation site. [1] The standard linux ARM distributions are armel (ARMv4 using method supporting floating point that is compatible with software FP and hardware FP but is relatively slow) and armhf (ARMv7 with hardware FP required). Rasbian is Debian recompiled for ARMv6 with hardware FP (with kernels and a few other bits also available in ARMv7 versions for Pi2s).