• 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

436 Neutral

About lc_overlord

  • Rank

Personal Information

  1. OpenGL

    I have basiclly two solutions to this issue   1. send points to the geometry shader and use it to draw cubes, this should be good for when you have a lot of freemoving cubes or basically cube particles.   2. if the terrain is more or less static then assembling the vertecies, normals and texture coordinates manually into raw ttriangles and then pushing it into a VBO is the way to go, even with the simplest possible culling it's fast enough that you don't have to mess around with indices at all.
  2. This pice of code is pretty ancient and im unsure if it even works with the latest Visual studio or how easy it is to fix it as i havn't run this code in a few years, i know it works for MSVC++ 6.0 but that version didn't even have namespace implemented. It would probably be better today to just go for the TGA tutorials and drop this whole glAUX nonsence.
  3. The error your getting is from openGL itself 2011-11-09 20:10:28.614 ********[16309:207] GL ERROR: 0x0500 a quick look trough gl.h states that error 0x0500 is GL_INVALID_ENUM. It could be that texture.name is not a valid enum or the fact that your binding it after glTexParameterf. Alternatively it could be because of quirks in openGL ES, but i don't think so.
  4. It's most likely because the lesson doesn't use a delta time value, instead movement is based on how many frames are rendered, so any inconsistencies in the frame rate show up as shaking or stuttering in the movements, adding delta time compensates for that, so do skip ahead to lesson 32 an learn how to implement it.
  5. if you look in the function InitGL you will see these two lines glBlendFunc(GL_SRC_ALPHA,GL_ONE); // Set The Blending Function For Translucency glEnable(GL_BLEND); This means that instead of replacing the color when overdrawing it will instead add to the color depending on the color and alpha of the texture your drawing. Try commenting them out and see what happens.
  6. If you really still want to load bmp files then lesson 6 should still work, just replace glaux with the replacement code below in my signature, it should still work. Otherwise you should take alook at lessons 24 and 33 which deals with tga loading and is much more appropriate for openGL use
  7. [quote name='GottiJay' timestamp='1309070798' post='4827800'] Thanks alot for your help i am very grateful.....one final question, after creating the loader and i was planing on loading multiple models i should not need an extra loader for each separate model ? [/quote] Not if you wrap it in a class, then you can just create a new instance of that class for every model you choose to load.
  8. [quote name='GottiJay' timestamp='1309011173' post='4827576'] large model sizes...my model has 11,000 polygons [/quote] That's not that large. The way to go about it is fairly simple, first you will need a header that contains all relevant information like the number of polygons and where the data for vertex texture and normal information start, Just having a array of unsigned ints is preferable. Secondly, just write the data, it's not that hard, writing a file spec is preferable though so both you and anyone else can replicate it with ease. You will probably go trough several formats before you settle on something more permanent, but that's just a part of the learning process. The hard part is not creating the format, it's exporting to the format that's why i recommend that you first make a obj loader and make that work, then make your own format. http://en.wikipedia.org/wiki/Wavefront_.obj_file
  9. No loader i know of selects according to size unless they have some kind of LOD system in place, most don't and even if they do it would still load something. The ms3d loader should not have an upper limit in theory, though i really don't know much about the format myself so it could be hitting the 64k limit somewhere. It really depends on the model and model format, which is another thing, this version of ms3d is an older version which could be your problem, so it shouldn't really be used anymore, obj should still work, though preferably you should make your own format and convert collada files to it. What you mean with " large model sizes"? 1k, 10k, 100k, 1M, or more polys?
  10. The main problem your having is that for the MODELVIEW matrix you normally call glLoadIdentety at the begining which resets the matrix to 0. But this is normally not done for the PROJECTION matrix so in your case this means that for every frame you rotate it a little bit more, but it doesn't reset so it just keeps adding and adding resulting in the spinning out of control effect. Now it really doesn't matter where you do the rotations since in the end both the modelview and projection matrices are multiplied with each other. It also doesn't matter how you do this, where you place this code or how many times since the amount of time it takes to do this is insignificant, especially since you should be fill rate limited. So in your case to fix this try GL11.glMatrixMode(GL11.GL_PROJECTION); GL11.glLoadIdentity(); GL11.gluPerspective(45.0f,(GLfloat)width/(GLfloat)height,0.1f,100.0f); GL11.glRotatef(lookupdown, 1.0f, 0, 0); GL11.glRotatef(sceneroty, 0, 1.0f, 0); GL11.glMatrixMode(GL11.GL_MODELVIEW); [quote name='lildragon555' timestamp='1308409697' post='4824810'] Don't you have to do glPushMatrix() and glPopMatrix() whenever you do any rotations, translations, or scaling? So it'd be [code] glPushMatrix(); GL11.glRotatef(lookupdown, 1.0f, 0, 0); GL11.glRotatef(sceneroty, 0, 1.0f, 0); glPopMatrix(); [/code] [/quote] no.
  11. no it's only one quad, if your doing texturing you need at least two sets of coordinates for each vertex, the first set given by glTexCoord2d signifies where on the texture you should read from and the second given by glVertex2d is the position on the screen, it's all really simple once you get a hang of it.
  12. parallax occlusion mapping is pretty much one of the last things you should concern yourself with right now, sure it's neat, but what you need to begin doing is first geometry rendering or making sure your using VBOs and things like that to make it really fast and solid, secondly you need to focus on the high visibility stuff or what is still going to be visible is you stand really really far away from the monitor (or squint with your eyes really hard). That usually mean lights, shadows and textures. Beyond that i can't tell you any specifics without seeing the old game and knowing a little about your graphical ambitions (creating a mock-up of what you want in blender/lightwave/maya/max will help you a lot with that). But in general for the generic 3d game i would today recommend deferred rendering with depth shadow maps and post process filters (you can skip the deferred part if you only use one or two lights or have very basic lighting). The most important bit is to take it one step at a time, preferably without breaking the rest So 1. get the geometry sorted out first 2. figure out how the lights are going to work individually and accumulate them into an FBO 3. make sure all of the different parts are up to date (you wouldn't want your textures to suffer because your not using anisotropic filtering) 4. try and make it all work together at once, the way you know this is done is when you have an elegant solution with few or no workarounds. 5. now you can do stuff like parallax mapping Another thing you do need to take in consideration is that a game will look better if it plays better so it would be wise to work on improving the gamecode over all and upgrade all parts of it, everything from input handling to physics to AI to sound, try and improve it all if you can that is. And don't forget to upgrade you actual game data. But please ask if there is anything specifically (additional information would be great in that case)
  13. For your first question you can check out the link in my signature below. Regarding the data folder, if you run it from visual studio then i think the folder location is correct, otherwise it should be in whatever folder the .exe ends up in, well at least that's the default behaviour, your setup could be different so check around a little.
  14. [quote name='SagoO' timestamp='1300445068' post='4787408'] [font="Arial"]Do you means texture buffer? I dun wan to render any display. [size="2"]How about I create one-dimensional texture objects to store those array? Eg: If I have 100 packets, I create 100 texture objects. Then, use shader to process every texture object in parallel. Will this work?[/size][/font] [/quote] no just a plain old texture, you can use an FBO to render to, that way you don't have to have any output. A 1 dimensional array could work but it's far easier to just cram it into a 2048x2048 texture, that way you have packets in one dimension and the data in one, what works best depends on exactly your algorithm, but that is something you have to find out for yourself. Another thing to try could be either Cuda or openCL as they are more adept to this kind of work.
  15. actually in that case i think it might be better to put all the packets in a 2048xN texture instead as it would allow you to access every packet in the fragment shader, then all you just render a line or a quad matching the output you like (you take it's coordinates and use it on the texture in one or more axis) and finally use glReadPixels to get the data.