Jump to content
  • Advertisement

technohermit

Member
  • Content Count

    11
  • Joined

  • Last visited

Community Reputation

136 Neutral

About technohermit

  • Rank
    Member
  1. Um, if you save the distance between the objects for one frame, then next frame simply test to see if the +/- (sign) of the previous distance and the current distance are opposite. If they are, you DEFINITELY had a collision! If not, you can perform the normal test (collision = )distance < ball-radius)). :-)
  2. technohermit

    OpenGL vs. DirectX

    I think the previous messages give some good advice. For whatever this is worth, I learned DirectX when I took a contract to create the game engine (and the guts of the first game) for a commercial game development company. So I guess it is reasonable to say I understood DirectX pretty well by the time the game was complete and released to market. A few months ago I had to create the guts of a new 3D engine from scratch, which had to be based upon OpenGL for portability reason. Having gone through a painful learning curve with brand X, I was not thrilled to repeat the learning curve again with brand Y. Anyway, seeing your post made me think my experience might be helpful to your question. But remember, we all have different tastes and reasons for our preferences, so possibly your experience could be opposite mine. The first week or so was definitely getting used to a new approach to 3D, which is to say, the way they work *is* different - or about as different as they can be given they end up being almost identical, functionally. However, after the first week, everything thereafter was a major relief! It was like having a thorn removed after you kind of got used to the pain. For me, the difference is that significant. While I know some developers out there might be able to have exactly the opposite experience, it is actually difficult for me to believe it deep inside. Yet I know tastes *are* often that different. Specifically, when working with the OpenGL API, I find my thinking process is about 3D, graphics, the architecture of my application, things like that. When I work with the DirectX API, I find my thinking process is often about finding or remembering or looking-up arbitrary details - the "how do I get done what I want). It feels like one extra unnecessary level of information to remember and cope with --- which almost seems to vanish with OpenGL. That was my experience. Depending on your goals and your own preferences (likes and dislikes), your experience could be different, even opposite I suppose (even if that is difficult to imagine from inside my skull). Oh, one important difference (mentioned by others) is not a matter of taste. If you think you'll ever be creating 3D applications for other platforms, you might want to choose OpenGL now - because then you won't need to subject yourself to a learning curve repeatedly like I did. Actually, it was three times for me (because the first 3D engine I wrote was 100% in my own code with no "helper" API beneath - just linear memory mapped onto the screen). Good luck.
  3. Yes, maybe, probably. But unless somebody does a serious and careful analysis, we are just repeating the conventional wisdom that is being reasonably questioned here. Any honest person *must* admit, it is easier to repeat the conventional wisdom and say it is "obviously" correct, than to carefully and methodically "prove it" - or make an actual case for it. I do not think ANY of us has done that yet, though the cobblestones and scales and similar cases are clearly the best place to start. So far, we are just hand-waving and repeating conventional wisdom. Admittedly, that is oh-so-much easier, but are we really certain that 3D geometry cobblestones and scales are *substantially* worse to render as 3D geometry? I ask it this way because we are ALL certain that 3D geometry is the best way to display an awful lot of things. If we display everything that way, we could put all our efforts into optimizing and polishing that code --- and guess what, far less switching shaders back and forth between so many different shading techniques. Which is much better from the proven "fewer batches is better" point-of-view.
  4. Here is my two cents to the replies so far. The original post admits the presented example was chosen to "stress the point" slightly, so POM comes out looking really horrible in many ways. However, is it actually clear that POM and POM-like techniques are ever substantially better in fully modern, up-to-date 3D graphics hardware. Because, if we find it is difficult to find cases where POM is clearly significantly "better" (faster/cheaper/whatever), the point of the original post becomes "due to changes/advances in the speed/memory/shaders in next generation 3D graphics cards, 3D geometry is rarely significantly slower or inferior to the so-called faked-geometry techniques". So, is it truly clear that POM is worth doing in the context of currently best graphics-cards - which will be mainstream in 1~2 years and old-hat in 3 years. Here are the cases where POM seems like it *might be* better (to some degree). Where almost all of the geometry is near the highest level - like in many cobblestone walls or sidewalks. In these cases, the camera-view-ray will usually intersect the geometry within two or three iterations - even at the slow pace of 2~3 pixels per step. In a case like this, you still benefit from POM over normal-mapping, because there are deep grooves between cobblestones which can exhibit substantial parallax that normal-mapping cannot represent. I had a couple other situations in mind, but now I realize full geometry does work better in those cases. Still, the above case does look to me like a possible win for POM --- as long as none of its inherent defects matter. Which means, the camera must not fly down into (or nearly into) those grooves between the cobblestones, because this becomes more like the originally described case where 3D geometry wins. And the camera should never get down close to the cobblestones, because then the "streaky" character of the near-vertical grooves in the cobblestones become obvious artifacts of fakery. So, I guess we must carefully examine this case that seems to be a win for POM given the context and limitations I mention above. If we cannot prove this truly is a win for POM (or relief/parallax/similar-mapping), then the original post seems pretty much entirely valid. Fact is, quite surprisingly, the old-fashion way *does* look alot better than might be expected, I think, and for exactly the reasons he suggested, probably. In thinking about his idea, I realized it seems entirely practical to make a very convenient LOD scheme based on the geometry approach, based upon what is pretty much the conventional efficient approach today with OpenGL IBO/VBO pairs (or DX index-buffer/vertex-buffer pairs). What you do is this. You have all the vertices in one VBO/vertex-buffer, plus one IBO/index-buffer for every LOD you want to support. Each IBO references just those vertices in the one VBO that it needs to construct the object at the desired resolution. Presto, you have LOD with only one set of vertices. This is surely not original, but hey, it works. So, where are we?
  5. technohermit

    new game engine

    team name to-be-determined by team project name to-be-determined by team brief description #1: game engine team We will complete an already working, partially-complete 3D game/graphics/simulation engine appropriate for developing 3D games and scientific/engineering/other simulations that require rich, complex, multi-component, multi-level articulating, realistic-as-possible object appearance and behavior at real-time frame rates with current/next generation video-graphics cards (roughly == nVidia 7800 and later). The core of the 3D game-engine has already been created by the poster, and is available as a starting point. The poster also contributes other software that is useful for the project but not yet integrated into the engine - for example, a code-library that is a suitable basis for game asset/resource management. Some technical details of the existing engine [and plans] are described below. #2: game team We will develop a game that takes advantage-of and thereby demonstrates the strengths of the game engine. The nature of the game is subject to change at this early stage, but should require realistic object appearance and physical behaviors and high 3D engine performance. The current game idea is set in space (in this solar system or possibly some other one), features huge space structures (up to many kilometers long) that contain huge quantities of multi-level articulating subsections for various purposes, and swarms of advanced, productive, self-aware robots (with human-level+ consciousness) and advanced distributed robotic systems. The game developer team are mostly unconstrained by the game-engine developers, as long as the game concept and implementation nicely matches the game-engine capabilities, features and strengths. target aim We intend this 3D-engine and our first-game to be revenue-producing endeavors, whether conventional commercial products or something more creative will be decided by the participants. The game-engine and first-game almost certainly will be marketed or produce-revenue in different ways. Some proprietary capabilites, features and technologies in our 3D-engine and subsystems that cannot be revealed in this message may/should give us major advantages over other 3D-engines. compensation For the moment, assume this project is speculative (risk/donate time/effort). If we demonstrate impressive early results, investment (and therefore some pay) is a realistic possibility. To the best of our ability to estimate, compensation will be proportional to the value/quantity/significance of the work each participant contributes. technology OpenGL 2.0+, GLSL (shaders), C/C++, assembly-language, SIMD-SSE3+, etc. This team is oriented-towards direct, efficient, maximum-speed, maximum-visibility, reliable and stable design principles. Therefore, to the extent possible, our application is our own code, with minimal libraries/tools/code from others. The current engine-core depends only upon OpenGL, glee and C standard libaries, but may incorporate good stable open-source libraries for certain subsystems. Some engine features that are planned or already [partly] incorporated in the engine as it works today include: "procedural object creation", "procedural object hierarchy assembly", "procedural object control", "procedural texture generation", support at least Windows and Linux and possibly Mac/others, remote control via network/sockets, eventual support for MDO == "massively distributed online operation" (which avoids expensive and problematic centralized server-system), advanced consciousness infrastructure, advanced assets/resources system, integrated collision detection/response, support for integration of arbitrary physics support modules, and more. talent needed #1: game engine team Four to ten programmers including the poster. The following talent is needed, but each participant needs expertise in only one category (at minimum). - programming experience with ASM, C/C++, OpenGL, GLSL, SIMD/SSE, etc. - experience with available open-source libraries for sound, etc. - knowledge of internals of existing/standard 3D object formats. - 3D game engine knowledge and experience - GLSL (or other) shader programming - other features wanted by adopters - website wizard #2: game team Five to ten game developers with the usual skill-mix: 3D object developers, sound developers, etc. Note: We do not need anyone without technical skills. All so-called "creative" positions like "producer" and "script/story writer" and such will be filled by participants who ALSO have at least one strong technical skill (create 3D objects, create sounds, program, etc). team structure The team structure is based upon individual responsibility. Each participant will be responsible for specific work and/or aspects of engine/game project. Everone is expected to know when they might benefit from (or need) the help or opinions of others - and ask for them. We need rational, sensible, practical, skilled participants - and zero mental cases. My experience in 3D/game-engines/graphics/programming is described later on. We already have 3D game/graphics engine experience in this group, so some of our engine-programmers can have little/modest knowledge of 3D graphics and/or game engines - as long as they are honest, diligent, realistic, thoughtful, careful, energetic, skilled and experienced programmers. Extra points for micro-programmers, assembly-language programmers, lowest-level programmers, embedded-systems programmers, and regular-old systems-programmers --- all of whom became realistic quick - or got locked away in mental institutions. website private at this time contacts please reply here (as appropriate) or send PM previous work by team I wrote large parts of 2 commercial video game engines (one PC, one PS2) plus parts of the first game developed on each; one complete (but limited-purpose) 3D (not-game) engine each in DX9 and OpenGL. I also wrote the core of a new 3D engine (OpenGL/GLSL/C/C++/ASM/SIMD-SSE2) that is the basis of this project. The engine core works and displays moving 3D objects in 3D space from the viewpoint of a freely moving and rotating camera/viewpoint. It supports only GLSL shaders (no code/path for fixed-function pipeline). additional info From long experience, I have learned to never be involved in projects based upon fancy [high-level] tools. Disaster = fads/fancy/hidden/complex/obscure. Thus, this project is appropriate only for participants who enjoy what might be called thorough/complete design and programming. To me, this not "low-level", this simply means doing the project ourselves so we understand how everything works and can configure the most efficient and effective architecture. However, for cleanly separable parts (perhaps "sound library" for instance) we can certainly consider reliable open-source libraries - especially if one of our participants has strong positive experience with certain libraries. feedback Please, ONLY honest attempts to make helpful observations and suggestions. [Edited by - technohermit on April 8, 2007 4:14:07 PM]
  • Advertisement
×

Important Information

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

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!