Jump to content
  • Advertisement

badsector

Member
  • Content count

    116
  • Joined

  • Last visited

Community Reputation

184 Neutral

About badsector

  • Rank
    Member
  1. Get the Nikwi graphics for free, for *any* use. Any use means that you can use them as you like, including making a new game with them, modifying them, using for your game's prototype, using for webpage graphics, screen wallpaper (?) or anything :-). The archive contain more than 170 images in bitmap (bmp) format and the same graphics in XCF (GIMP) format, decomposed to their layers (most of them are around 6-7 layers) for easier modification. I'm using this as a "promotional material" for my freelance offering which can be found in this IGF thread :-). In short, it says that if you want graphics like these, just contact me at badsector@slashstone.com. Screenshots from the game Nikwi which uses the above graphics can be found here. However here they are.
  2. badsector

    BSP collision detection

    I had this problem when i was writing the collision detection system in my Undead Engine, however it wasn't due to BSP... it can happen with ANY method. This hapenned to me because i was just "pushing" the camera's bounding volume towards the colliding face's normal, just enough to "touch" but not penetrate the face - and i was doing that for every colliding face. This worked in most cases, but not all. And it had jerky movement. Then i found this document, which describes how to create a "sliding plane" for sphere or ellipsoid-based collision detection. This sliding plane is used to project your velocity vector to it and then moving the object using the projected velocity vector. Personally i decided to not implement the whole algorithm, but only take the sliding plane idea and figure out the rest myself (it helped that i already had other stuff in the engine already working and i would have to rewrite them if i was going to implement the whole thing...). This document is very easy to read, btw. And while says nothing about BSP, you'll be able to use BSP with it.
  3. badsector

    Collision detection

    This isn't a hard task, every kind of collision detection is actually a matter of one or more intersection tests. An easy to implement way is to check if each edge (which also is a line segment) of the one triangle penetrates the other triangle. If so, then the triangles collide. Getting the collision points (which is actually a line segment) is a little more tricky, but if you draw the situation in paper, you'll figure out a solution. I just don't have the means right now to draw it for you :-).
  4. badsector

    Indy MMORPG development, can it be done?

    It may sound strange, but from personal experience i would recommend you to go 3D. While it may sound hard, in the long run is better and easier when it comes to some stuff (especially if you want to add some eye candy :-)). I also recommend you to forget Visual Basic for various reasons and stick to C++ for speed and portability reasons :-). Something that will help you with writing tool software is BSGUI GUI, an OpenGL and SDL-based GUI library i wrote (and still writing) for developing my tools. Currently i use it mostly in two tools: Immortal Editor - the world editor for Undead Engine, my 3d game engine and Slashy2D Editor (aka SlashEd) - the map editor for Slashy2D, my 2d game engine :-) Also i would recommend you to use SDL and OpenGL: both are more than enough to be used as a base to create a very good game :-). Designing server/client games may be a bit hard, but there is plenty of information at the internet on how to do it properly :-). In any case, if you think you'll need any help, drop me a mail at badsector at slashstone dot com. EDIT: if you -or anyone else- wants BSGUI, mail me to send you the latest WIP which fixes some bugs and changes a bit the API...
  5. And yet, when i say that Source engine is Quake1+hires truecolor textures+hires colored lightmaps+textured particles+skinning+some basic shadowing for models (which you could see in some games since mid-1999)+some shader effects (the "wow" water is included in that, but this kind of water has been done a bazillion times since pixel shaders came out), people say that i'm insane. It's the artists that makes HL2 be what it is... :-) But i don't really think that Torque can compete with UE3. It's lacking stuff such as HDRL, volumetric shadows, projected textures (ok, i'm not 100% sure about that but i didn't saw anything like that in the demo), precalculated spherical harmonics lighting and some minor touches that UE3 has. However a UE3-based game with crappy art will be worse than a Torque-based game with good art. But i don't think that someone who can afford to license UE3 cannot afford to hire good artists :-).
  6. badsector

    How to implement PVS calculation?

    No, i know what PVS is - if i gave the wrong impression, then my fault :-) My problem is that i don't know how to calculate it :-). Now i'm reading Teller's paper. It's big... actually huge, but seems good. What it describes seems to be exactly what i'm looking for (computing a PVS for interior scenes). Anyway... thanks for the replies and i'll see what i'll come up with :-P
  7. badsector

    How to implement PVS calculation?

    Umm, guys i know all this stuff you're talking about, i tried to implement a PVS in a grid-based partitioning, remember? :-). I know that portals are just one of the available methods to compute a PVS and BSP is just a method to get the portals. But anyway, thanks for your replies :-). Btw, as i said i'm using BSP for other things, so i don't think that there is a reason to use another space partitioning structure (such as octrees, quadtrees, or whatever else). Again thanks for the replies (and if anyone else has any idea please tell me about). @toe99001: well, yes... that's my major problem :-D @Sneftel: yes, that's it. And i'll probably do just that :-)
  8. badsector

    How to implement PVS calculation?

    Well what you describe doesn't sound as PVS engine, but as a portal-based engine. PVS is like: for each cell in the world (cell in my case could be the convex areas that the BSP leaves define) calculate which other cells are potentially visible. Then in the engine just pass only these cells to the lower level Hidden Surface Removal parts of the rendering pipeline (such as frustum culling and clipping) instead of passing everything in the world. A portal-based engine works like this: Figure out in which cell/sector the camera is and render the sector. Figure out which portal polygons are visible and clip the view frustum to them. Then render the cell/sector they point at with the new frustum. If the target cell/sector have any portal polygon, then clip the -already clipped- viewing frustum by this portal polygon and repeat this for the cell/sector the portal polygon points at. Repeat the same process for every portal polygon you'll find until no more portal polygons or until the frustum becomes extemelly small (1 pixel?). Having said the above, i've heard that Unreal Engine is a portal-based engine, so things won't be that slow without PVS (if portals are used). But a main problem is that i don't really know how to calculate the portals...
  9. badsector

    How to implement PVS calculation?

    Actually i mostly knew what you said. From what i read on a site, Quake computes the portals by creating a large polygon for each intersection plane that goes out of the level's boundaries and then clips it with the planes of the children of the node that has the intersection plane. The "remaining" is a potential portal polygon. Then it somehow figures out which of the potential portal polygons are actual portal polygons... and then somehow using these portals it computes which parts of the tree are visible to other parts... [knowledge on the topic stops here] The problem is that i can't find any page with clear information on how to calculate PVS (note that i don't require it to be the method that Quake used) or portals (or both if one requires the other). Also i'm not sure what to do once i find the portals. I don't think that raycasting from one cell to others actually works; at the past i wrote a "2.5D" software rendering engine for which i was calculating a PVS by dividing the world in square cells and shooting rays to see which walls are visible from a cell. The problem is that from some points in the cell a wall was visible and from some other points, it wasn't (and shooting ALOT of rays wasn't a solution - there always was some cases where i was "between" points where a wall should be visible but it wasn't). A solution would probably be to test each "out" cell (the cells that are outside the cell we make the PVS entry for) for being visible to the "in" cell by projecting all polygons it has on the portal polygon's plane, then clipping the projected polygons by the portal polygon and marking the cell as "visible" if any of the projected polygons is inside the portal polygon or "invisible" if all of the projected polygons falls outside the portal polygon. However i have a great feeling that this is wrong...
  10. I'm looking for information about this subject for a couple of days now and i can't find some good documentation (everyone seems to have just an "idea" or something -but i can't find an explanation of how to actually do it). In my Undead Engine, i've already implemented BSP which i use for rendering, collision detection and frustum culling. So now the next thing i want to do before proceeding in other stuff (such as some more eye candy effects :-)), is to implement PVS. Unfortunatelly information on PVS is not as near as good (and popular) as on BSP trees and while i have three books on computer graphics, from which two of them are about game programming (the books are "3d computer graphics" by Alan Watt, "3d game engine design" by David Eberly and "tricks and tips of the 3d game programming gurus..." of Andre LaMothe), none of them explains PVS (tricks explains how to use them, but the explanation on how to calculate them is very bad). I've found a paper by Teller which is supposed to provide what i need, but... well... i can't say i understand much of it (it could be that it's very long -more than 60 pages i think- and i'm easyly getting tired when reading text from the screen...). So, has anyone implemented a PVS generator and can help me on this? I'm really stuck :-(
  11. You only have to license your program under GPL (in which case you can still sell it - GPL allows that - but you have to release the source code too) if the GPL program you use links parts of itself or other GPL code with your program. For example, if you use a GPL library then your program must be licensed under GPL. As far as i know, the libraries that come with a "core" (ie with not additional "packages") Dev-C++ allows you to link at them without problem.
  12. badsector

    Opengl glow...?

    (seeing the nickname) in C++ or Java? :-p Well i would be interested in anything about HDR, since i know zero (well almost) about this. @kc: It depends on your "blur" and "contrast" filters. The less the blur, the more the sharpness (but from a point and after it won't be glow anymore). Also the more the contrast (=the larger the N), the less the amount of the image that will be presented in "glow". Experiment.
  13. badsector

    Opengl glow...?

    wow, 5 additional replies while i was writing this one :-P
  14. badsector

    Opengl glow...?

    A method without pixel shaders is... 1. Set the viewport to 512x512 (glViewport(0, 0, 512, 512);) and render the scene. 2. Download (grab) the framebuffer to a 512x512 buffer (glReadPixels(0, 0, 512, 512, GL_RGB, GL_UNSIGNED_BYTE, pixelData);) 3. Apply a "blur" filter to the pixelData. Check Gamasutra for an article on fast blurring. 4. Apply a "contrast" filter to the pixelData. Do something like channel = channel / N * N for each red, green and blue channel (the greater the N, the bigger the contrast). 5. Upload the pixelData to a 512x512 texture. 6. Set the viewport to your nornal viewport (f.e. glViewport(0, 0, 800, 600); for 800x600 mode) and render the scene again. 7. Enable blending (glEnable(GL_BLEND);) and set the blending function to perform additive blending (glBlendFunc(GL_ONE, GL_ONE);). 8. Draw a quad at the whole screen that contains the texture you made at step 5. 9. Disable blending. 10. Show the rendering (flip the buffers - SDL_SwapBuffers() in SDL). and that's it. (probably :-P) The above method will add a glow effect in all bright areas, which is not that good. You probably want to do something else: instead of rendering the scene in step 1 with usual materials, use "glow materials" (f.e. glow textures) and render only the objects which have a "glow material". This will have a better result and probably speed up the rendering because you'll only render objects which have glowing.
  15. badsector

    cross platform GUI?

    I've made this one. It is supposed to be cross platform (compiles without modification under Wind32 and Linux, at least). It relies on SDL and OpenGL and provides a nice Object Oriented API in C++. There is also a tutorial in there and an example application. It is licensed under the terms of the MIT license. However it is somehow limited in capabilities and there is a bug (which is fixed in my hdd version), so if you use it contact me to send you a better version. I don't think that i'll do that soon, but keep in mind that i may change some things. I say that i don't think that i'll do that soon because i tend to think alot of my interfaces before i implement them. But then again i can't promise anything :-). The library requires your application to be written using SDL, however. That's not a major problem, since SDL is ported to many platforms :-). Also you need to manually initialize OpenGL and SDL (you can copy/paste the code from the example app, if you like) and put the GUI rendering function at the end of your render() function (or whatever you named it). I did it that way because i wanted to use it in existing OpenGL applications :-). At the future i will probably add OpenGL/SDL initialization and shutdown functionality, it's not hard; i just didn't wanted it. The GUI is rather simple coded and straightforward. Even if you don't use it, it will be a nice way to learn how to write your own.
  • 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!