• Content count

  • Joined

  • Last visited

Community Reputation

210 Neutral

About aerojockey

  • Rank
  1. TL;DR: I learned graphics from GW Basic programming manuals, a book called Tricks of the Graphics Gurus, the Open GL Red Book, and web tutorials/references.  The math I learned in college helped, as did studying some open source programs like Fractint.  I put my graphics background to quite good use in my current Aerospace job.   I learned programming and graphics programming by reading through old GW Basic manuals.  I wanted to write games like Commander Keen and Space Quest, but obviously Basic was not up to that task (you couldn't really animate without terrible flicker).  With the help of a cousin, I eventually found out about C and assembly language, and learned about EGA/VGA programming, but the VGA was tricky to program in 16 colors (it used bit planes, so you couldn't write to a single pixel with one operation, you had to make four writes, one for each plane).  I studied programs like Fractint to see how they did it.  Also, I bought this book (which was prominently displayed at Radio Shack):   The book was a tad disappointing in that it didn't cover too much about the low-level VGA, but boy did it teach me a lot of graphics background and techniques, many of which are still useful today.   In college I lost some interest in game programming; I had other things to worry about.  I majored in Aerospace Engineering (I figured that I already knew enough about coding and a CS degree would just waste my time).  But the Aerospace degree did teach a lot of useful math.  And it did help me to write one rather famous graphical program: a low-end wireframe flight simulator for X Windows.   As I was wrapping up grad school, I got back into game programming, this time in the 3D world.  I'd had a bit of exposure to Iris GL in college, and took up its successor, Open GL.  I just bought the Open GL Red Book, read it through, and have been slowly growing my skills ever since.  I was, and am, really happy Open GL took care of writing to the pixel buffers for me.  I hated that.   Now, as an aerospace engineer, I find that all that effort I spent learning graphics has paid off.  A nice animation can really help to communicate ideas and results to other engineers and (especially) engineering managers.  Since I have these skills, and most of my colleagues do not, I get a lot of good stuff to do.
  2.   Fair enough, and I'd agree with you 99% of the time that that's the appropriate way.  The particular user-experience-improvement features I'm thinking of won't work if the user has to explicitly enable them, though.  (That's probably hard to believe; all I can say is my game is not a typical game and what I'm thinking of is very, very meta.)   I'll keep the objections raised here in mind.  I've been watching some streams and I have few ideas on how to divine whether someone is live-streaming behaviorally.  If it proves to be something I can't figure out how to do inoffensively enough, I just won't put the feature in.
  3. I'm not sure where else to ask this, it's a pretty esoteric question, but it is game related.   I was wondering if someone has any ideas or knowledge on how to detect if someone is live-streaming the game.  It need not be foolproof.  My first strategy would be to query the system process list and see if there are any well known streaming applications running, and I figure that would work well enough for my purposes.  But maybe there's a better way?  Like a graphics state you can query to see if it's being recorded, or maybe looking at active network connections (unlikely since it would almost certainly need admin/root rights).   This is not, incidentally, some kind of hare-brained anti-piracy scheme.  I would never do that; I owe the popularity of my game to various people live-streaming and making videos of it.  I want to detect live-streaming for quite the opposite reason: to improve the experience for people watching the live-stream.   Thanks.
  4.   Actually there is.  Strategy on timing of creation and deletion of data can help out the driver.   Fragmentation is a tricky problem; there's a trade-off with performance.  If data are allocated and deallocated all the time in arbitrary order, gaps in allocated memory can appear.  If you are able to stick a small piece of data in a gap, it makes it less likely to lead to memory fragmentation down the road.  However, tracking all those gaps makes allocation an N^2 operation with the number of allocated data chunks, which can kill performance.  Strategies like compaction can affect performance as well.  Therefore, there's typically a complex strategy to memory management that balances performance with minimizing fragmentation.  On a desktop PC which has lots of speed and memory, the algorithms do pretty well, but they might not do so well on a smaller device with less available RAM and throughput.   But there are things you can do to help keep it simple for the driver.  The most obvious is LIFO (last in first out), always deallocating data in the opposite order they were allocated in, which would completely eliminate gaps.  Since I can't do that any more, I am thinking of how I can still keep it kind of simple, so that when the game transitions to phones and such, there are no unexpected crashes or missing textures.
  5.   FIFO for the rescue ? Or more dynamic LRU cache ?   FIFO is no more possible as LIFO.  As a character wanders around different resources must be loaded and unloaded in arbitrary order.  FIFO might be possible on a racetrack.  I'm not sure how LRU cache would help alleviate fragmentation; my gut feeling is that it'd make it worse.  (For that matter I'm not sure how you'd implement this with OpenGL other than to start deleting old data when you get allocation errors.  But that seems like bad design.  Are there any extensions that can unload old data?  I haven't read up on them recently.)   I'm not sure if you caught that I was talking about GPU memory.  These strategies (like pooling) assume you have ability to freely lay out data in GPU memory, but unless you're thinking of some extensions I don't know about, GPU memory is handled by the driver.
  6. I was wondering if anyone had any recommendations on the best way to manage memory/resources (textures and vertex buffers) for a wide-open sandbox.   Heretofore with my game I've been able to get away with a strict LIFO policy, but with a wide-open sandbox I am loading and unloading in the background so a LIFO strategy is not possible, and this I fear can lead to memory fragmentation.  I'd guess that naively letting OpenGL manage memory would work well enough on a PC with mature drivers, but I'd think that might not be the case for less mature drivers, and platfoms like phones.   If worse comes to worst I suppose I can delete and reload all the resources if I encounter a memory error (I already have that capability anyway, since my underlying application library can't manage to keep the same OpenGL context when switching between full-screen and windowed mode).   Thanks
  7. Portal for a free demo?

    I have completed a smallish, free demo for a PC indie game. I'd like to distribute the demo from a game portal, but I haven't been able to find a good option for free demos. (One complicating factor is that Googling for "game portals" usually returns hits for the game Portal....) I wouldn't mind paying a small fee. The demo is not likely to ever turn into a full game.   I could just distribute the demo from my website, and that would be fine, but a portal adds a bit of perceived legitimacy. Also, the portal could provide download stats. (I could, of course, write scripts to extract that information from my server logs but I don't really want to.)   So, if anyone has a suggestion I'd like to hear it.   If you're curious, this is the game:    
  8. Joystick sign conventions

      I actually just noticed this.  The game is multiplatform, and the D-Pad is considered a joystick on Linux but a D-pad on Windows.  Furthermore, the D-pad sign convention is positve up.  Nice of them to keep things simple.  Since the distinction is irrelevant to my game I'm going to make hats into honorary joysticks.
  9. Joystick sign conventions

      For those people I have my "Advanced Controls Setup" option; namely editing the control settings file with a text editor.  :)  Thanks for the advice.
  10. Quick question--it's so hard to Google for answers like this one: Is the sign convention for PC joysticks or D-pads something I can generally rely on?  It seems that the horizontal axis is positive right, and the vertical axis positive down, and the horizontal axis has the lower axis number.  If that's true for all joysticks, then all I'd have to do to detect the correct axis mappings is to ask the user to move the joystick around the perimeter a few times.  If this is inconsistent then I'd have to map the horizontal and vertical axes separately.  Thanks.
  11. I was just wondering if anyone has any advice on how to approach this. I'm pretty close to a releasing a 3rd-person action-adventure demo I've been making; I just need to tie up controls and other loose ends. I used a Logitech Rumblepad to develop the game. But in order to reach as many people as possible it should be comfortable to play with keyboard and mouse, and be flexible to other gamepads. I'm not much of a PC gamer (ok I don't play PC games at all) so I don't really know much about how PC games handle controls at all. I figure that's the main problem here, so I guess I'll just get hold of some PC games and do whatever they do (and I'm happy to accept suggestions for any PC games that do an exemplary job with controls). But I wanted to see if anyone who's faced this problem has some advice. Does anyone know of a project to collect gamepad definitions? Thanks.
  12. Voiceover?

    Hello, I am more or less done with a short first-level demo of my game, and the main thing it is missing is voiceover. (I will mention that the game really is designed for voice and would suffer for not having it.) I want it to sound better than a bunch of my untrained friends over a webcam microphone. Problem is, I have no idea how to go about recording decent-quality voiceover. I figure for voices I could get a good deal on some drama students from the nearby university. For recording, I don't know. Rent a studio? I don't need a world-class sound stage but cheapest ones I could find around here are pricey. Buy or rent equipment and do it in my apartment? Don't know what equipment I should get. I'm pretty much an audiophobe. Plus I'm not sure about bringing random college kids to my abode. I have a budget in the hundreds of dollars for this (no fixed number, it's a trade-off at this point). Does anyone have any experience or at least has some educated advice? Note: My question is only about recording. I have no questions about post-processing; I'm all good there. Thanks.
  13. Upon further searching I think I have a good candidate: pango. It's not a complete solution since it only lays out paragraphs (I'll have to manage higher level structures like columns and tables myself) but it manages fonts and glyphs and so on, which is the hard part. It'll render to a pixmap and I think there might be direct OpenGL rendering backends that exist. It also has a markup language, the XML subset of which is nearly (maybe wholly) powerful as the whole thing, so it will be no problem to integrate into my existing XML markup. It handles international characters as well (which I forgot to mention I'll need). And it's much, much lighter weight than webkit or gecko. I'd still be willing to hear other suggestions though.
  14. Quote:Original post by mercior glBegin (GL_QUADS); glVertex2f ((float)width/4.0f, (float)height/4.0f); glVertex2f ((float)3.0f*width/4.0f, (float)height/4.0f); glVertex2f ((float)3.0f*width/4.0f, (float)3.0f*height/4.0f); glVertex2f ((float)width/4.0f, (float)3.0f*height/4.0f); glEnd (); Looks like you're not setting texture coordinates when you draw the framebuffer texture, which means you are only drawing the bottom-left pixel. Try this: glBegin (GL_QUADS); glTexCoord2f(0.0f,0.0f); glVertex2f ((float)width/4.0f, (float)height/4.0f); glTexCoord2f(0.0f,1.0f); glVertex2f ((float)3.0f*width/4.0f, (float)height/4.0f); glTexCoord2f(1.0f,1.0f); glVertex2f ((float)3.0f*width/4.0f, (float)3.0f*height/4.0f); glTexCoord2f(1.0f,0.0f); glVertex2f ((float)width/4.0f, (float)3.0f*height/4.0f); glEnd ();
  15. Quote:The only place I was able to find any info was an nVidia tutorial, which didn't go into much depth on it either, other than mentioning that the S/T/R texture coordinates are set to the eye-space vertex normals. GL_NORMAL_MAP works like this. Say you have sphere and you want to draw a smiley face on it, and you want the smiley face to always point to the camera. GL_NORMAL_MAP may be for you. That's probably not what you want. If you want reflection (and you probably do, it's the main reason anyone uses cubemaps) you should use GL_REFLECTION_MAP. Another rare reason to use cubemaps is in some cases you have an odd-shaped convex object where it might be easier to generate a surface with a cubemap, especially if the camera is inside the object; in which case GL_OBJECT_LINEAR might be appropriate. Quote:Without knowing more details, it behooves me to mention that 'neutral' on a normal map is 808080 -- that is, a normal of +z is 8080FF, not 0000FF. Similar for other axises. 0000FF would be [-1,-1,+1], which would be one of the corners ('45 degrees') of the normal space, not one of the edges. He's not talking about a normal texture map, but automatic texture coordinate generation for vertices, which (unfortunately) involves a constant called GL_NORMAL_MAP. It causes OpenGL to "map" the normal vector for that vertex to the cube map texture coordinates. Quote:Fixed-function is dead. No reason to spend any time learning it. Learning to implement normal mapping in a shader is far more useful RDragon1, The best way to convince people to adopt new technology is to show that you have mastered the old technology (i.e., by answering the guy's question); that way it looks like you understand why the new technology is better and you speak from experience.