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

Pseudo

Members
  • Content count

    366
  • Joined

  • Last visited

Community Reputation

100 Neutral

About Pseudo

  • Rank
    Member
  1. If you are asking this question at all, I suggest you stick with C++ or possibly something higher level like C#. You really shouldn't waste your time debating over a couple % difference (if that) when you could be learning so many more important things in game dev.
  2. I wonder if there is a term for people like Dannthr. We've all seen the type. They think they have big ideas, they tell everyone how great their project is _going_ to be, they have a small 'staff' of typically students or homeless people, they generally have no clue what goes into making a AAA title, they under-estimate problems, time costs, startup costs, distribution costs, etc, and over-estimate everything else. They generally dont even have a design document or any features really speced out. They think they can somehow do what hundreds of others (with larger budgest, and real experience) have failed to do. They like to _play_ games. I'm going to call them "idiots", but if anyone know a more descriptive term, please let me know.
  3. try a double pointer. ie. float** charWidth
  4. Well you're CPU will probably be pegged at 100% either way, but the real indicator is frames per second. If your FPS is acceptibly high, then leave it as is, on the other hand if you are getting bad FPS (say <30fps), you may want to devote the time needed to switch to SetTransform. Its hard to tell which would be faster, but if your models are really small then CPU may be better. If you are using a lot of sprites, then you might want to try using D3D's point sprites. They are optimized fairly well.
  5. I dont see anything in your description that could be done any other way. The server MUST listen for connections and the clients MUST connect to servers. Am I missing something? The tricky part is in how the messages are handled. Usually you want to timestamp all your messages and do some form of dead reckoning on the moving objects. This can get quite complicated if done right but start with something simple and you should be able to expand it later.
  6. What's "lots" of DrawPrimative calls? I would do it the normal drawprimative way first, and only devote the effort if it becomes a performance issue. Doing preemptive performance optimizations is typically a bad idea in my experience. On the other hand if you're talking about doing like 10000 little objects, with few vertices each, it might make sense. It all boils down to what you consider "lots". On another note, if all your objects are not using the exact same texture/material/shader/etc then you're going to have to do lots of DP calls anyways. (or at least one per combo of the above)
  7. Old cards can only support power-of-two sized textures. Newer cards can do any reasonable sized image with an extension.
  8. With respect to porting, opengl would be good for this. In terms of speed, using glDrawPixel OR your own custom drawing routines for lines/images/etc will be much slower in most cases because GDI+ already accelerates this with the video card. You COULD create a vector based gui system with opengl and do the images as textured quads instead of glDrawPixels and your system may perform quite well. This is exactly what Avalon does, and I'm sure there are some open source systems that use opengl to try to do this as well. For that matter OSX's Quartz rendering system uses opengl to some extent. The tiger version will use it much more...
  9. I'm suprised nobody has asked this yet. Why do you want to re-make all of your controls? There are some good reasons, but I'm curious what your reasons are. Two of the best reasons to make an opengl gui api dont seem to be on your mind. The first is making it cross-platform. You said "windows controls" so it sounds like you're only thinking Windows. Is this the case? Also you talked about using glDrawPixels so it sounds like you're not looking to make a fully vectorised ui AND you're not looking to make it faster than GDI+. So what will OpenGL gain you? Do your controls support tablet inking? keyboard shortcuts? clipboard? accessability (text to speech)? I'm not saying not to use OpenGL, but if you do, make sure you have a good reason. Making a good system is a lot of work, so if you do it you would probably want it to be better than gdi in some respect. Also, check out the Microsoft Avalon CTP. It's a gui system that Microsoft is working on that uses Direct3D for it's rendering. If nothing else it can give you some ideas on how to do things.
  10. You probably weren't looking for this type of advice, but if you're not too far along you could always give Novodex a try. Its free for non-commericial use and in my experiance causes far less hair pulling than ODE. I started with ODE but after running into problem after problem I decided it was crap. This was a couple years ago, so I'm sure it's much better, but I thought I'd point out that it's very possible that it's not something you're doing wrong.
  11. nts is wrong. You can do it just like you are. Try using intermediate mode commands (glVertex3fv, glNormal3fv...) with the data from the array to see if the data is wrong.
  12. I'm working on a graphics demo that has some pretty interesting feedback effects. I'm bored so I thought I'd explain how to do it. first the screenshots are at: http://www.brandonfurtwangler.com/index.php?p=37 the feedback is shown in the last 3 screenshots. still images dont exactly do it justice, but you get the idea. To do this, I created 3 textures that were render targets. I call these 'current', 'previous', and 'mix'. Every frame I do this: 1) render scene into 'current' 2) render full screen quad/grid into 'mix' using a feedback shader (explained below) with 'current' and 'previous' as input textures 3) render full screen quad into backbuffer using a copy shader with 'mix' as a texture 4) swap around 'previous'/'mix' the feedback shader should warp vertex positions to give interesting stretching of the image, and it should lerp between current and previous in the pixel shader. If you scale the vertex positions, it will do a radial feedback/blur. If you rotate the positions it will do circular feedback and if you just move the vertices around based on time using sin/cos waves you get an underwater effect (this works best with a grid rather than a quad). You can then use your lerp's blending factor to easily control how much feedback you get. the copy shader just samples its input texture and basicaly copies from the texture to the screen. I have a few more screenshots showing the warping that I'll post tomorrow and if there's enough interest I could put the code up there too.
  13. Thanks for the link. I've read the doc that you linked, but I'm still unclear on how to do it in projection space. They offset the position half a pixel in screen space, but didn't say explicity how projection space is converted to screen space. I assumed you could also offset the texture coordinates, but it looks like 0...1 does map the entire texture based on that document. I was hoping this was a common thing to do and someone could just drop some code or explain it in a different way than that document.
  14. If I have a 512x512 texture that I want to render a full screen quad into so that I can copy another 512x512 texture into it such that the pixels line up exactly, how do I fix the position/texture coords for this? currently I have (C#): TexturedQuadVertex[] quad = new TexturedQuadVertex[4]; quad[0].position = new Vector3(-1,1,0); quad[0].texcoord= new Vector2(0,0); quad[1].position = new Vector3(1,1,0); quad[1].texcoord= new Vector2(1,0); quad[2].position = new Vector3(1,-1,0); quad[2].texcoord= new Vector2(1,1); quad[3].position = new Vector3(-1,-1,0); quad[3].texcoord= new Vector2(0,1); where my positions are in projection space...but I get a drift to the bottom right when doing this in a feed back loop. I need the pixel to line up exactly.
  15. without reading your code, I'd predict you either have flat shading on, or your faces are defined with repeated vertices. Try welding first and see if it makes a difference.