Pseudo

Members
  • Content count

    366
  • Joined

  • Last visited

Community Reputation

100 Neutral

About Pseudo

  • Rank
    Member
  1. c vs c++ for 3d engine design

    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. Attempting the near impossible! MRPG

    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. SetTransform()

    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. Designing a Networked Game

    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. SetTransform()

    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. ODE: running out of stack space

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

    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. At It Again...

    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.