Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Everything posted by MichaelDwan

  1. The first thing I notice is that it looks you're issuing a draw call for every single tile. Not to mention (potentially) changing texture and shader state unnecessarily. I'm assuming, except for position, all these tiles are being drawn in essentially the same way. Instead of drawing once for every tile, just bind your shader and texture, submit _all_ the vertices and indices at once and issue a single draw call.
  2. Been playing with the BlackBerry Z10 lately. I have to say, for me, its the most navigable mobile OS on the market. One hand, and you can swipe your way around very comfortably. Looks like iOS 7 is going in a similar direction, with more touch/swipe based navigation, as opposed to endless button tapping. Good stuff.
  3. If the government thinks I should be in debt for school... I think I should pursue a life of anarchy. I started by jaywalking two days ago. It was intense. Then, I pushed the walk button to stop the oncoming traffic!
  4. MichaelDwan

    Software Renderer Coordinate Issue

    How are you projecting the points? Where on the 2D view-plane do you expect the point to be projected if you do the math by hand?
  5. MichaelDwan

    How do I use classes with SDL variables

    Your return types don't match. In the declaration you use SDL_Rect* as a return type, in the definition you're using the struct keyword as a return type(which doesn't make sense, any way you hack it) SDL_Rect* Rectangle::make_rect(int x, int y, int w, int h) { }
  6. MichaelDwan

    Lua on a Mac

    Lua code compiles to run in a virtual machine. Just use the command line tools to compile it. http://devthought.com/2009/03/17/how-to-install-lua-5-in-mac-os-x-leopard/
  7. MichaelDwan

    Best openGL resource

    Exactly. I guess it may be a misunderstanding. That is, perhaps the reviewers mean that the authors spend 7 chapters DEVELOPING the GLToolKit (the ins and outs) instead of going straight to GLSL. But that would mean the tool kit has shaders in it, which leads me to think they are indeed just black boxing the whole thing. I was hoping someone here had read it and could shed some light on it. The two ebooks linked, I think, would do a good job of filling in the holes the SB5 would inevitably leave. So, I think it would still be a safe investment, I'm just boggled as to how a thousand page book would feel the need to approach the material that way.
  8. MichaelDwan

    Best openGL resource

    I've read often that the SuperBible 5 is really biased toward the author's GLToolKit or whatever its called. I understand what they were going for in order to introduce graphics programming, but its an OpenGL book, I don't really see the logic in wrapping OpenGL. Unless of course the ToolKit is built and explained during the book's progression. I think, if what I've read of the SB5 is true, that, maybe a better route (besides the two ebooks posted earlier which are very good,) is something like the Orange Book(OpenGL Shading Language) and OpenGL ES 2.0 Programming Guide.
  9. Hahaha. Very true. I get into old school mode when you start talking about P&C adventures, though.
  10. Alternatively to cutting the image up and layering it, you could use a pseudo depth buffer as well. In it you would have key-values (graphically for editing you could use something like Magenta or some other stand-out color), then, when drawing your sprites, check the buffer at the sprite's position and don't draw anything that collides with the Magenta value. Just a thought. I do think it would be more difficult to implement this efficiently than just layering, but, from a development standpoint it it would be quicker and simpler than chopping all your map screens up in randomly sized chunks.
  11. MichaelDwan

    VGA Programming

    You only have one option in Linux to work with the old VGA modes and DOS era game programming: Get DOSBox, and run you executables there. Otherwise, set yourself up a Win 3.1/Win95/Win98 machine. If i remember correctly, all of those will still let you screw things up if you want. Its been a long time, though. You'll also need an old Real Mode compiler, I always preferred Borland's Turbo C/C++. Another choice is DJGPP which will let you compile 32-bit protected mode programs as well as 16bit Real Mode. That will let you work with extended memory regions and SVGA stuff. As cool as all of that was, to be that close to what you were doing it isn't really reasonable nowadays. Instead, just choose an API that will give you access to to a "frame buffer" Like Direct Draw/SDL Surfaces, or Direct3D/OpenGL textures. Once you have that its just as old school: draw your pixels to an offscreen buffer and copy those to whatever your API choice is using to represent your "frame buffer"(this is probably just generating a texture from the raw pixel data in OGL/D3D) I suppose I should have left out all the DirectX stuff since you're on Linux, but you get the idea. I miss the old days, too, but really, there was a lot going on behind the scenes then too, it only seems simple because all we had to do was load some registers and "int 13h", now you just have to call a new blackbox entry-point, whichever you choose.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!