• Content count

  • Joined

  • Last visited

Community Reputation

128 Neutral

About vicx

  • Rank
  1. All from scratch

    Oh, come on... mmo is just a goal, he will quickly start to respect that word. I used to finished one, but I failed on content (graphics/stats/items) So, the only advise could be - get into C++ (if you want to be more serious in makeing games), alt is c#. Then try to find yourself in Visual Studio 2008 (make at laest playable text game, roguelike/mudlike), then get SDK for DirectX 9.0 and try to invest your language further, straight into world of triangles. Of course that's a huuuge shortcut. Distances between points I've posted are vast like desert. Besides, while writting your first code/projects you will realize whether you're strong enough to pass deeper. The main adventage will be stubbroness
  2. Hello again guys! There were some topics of mine about normals etc etc which I finally resolved. By reading some papers I came up to the point where my application is able to render 16x16 km terrain on my integrated gpu by using precomputed normalmap and few index buffers with different lods for one vertex buffer. Till now I was testing whole stuff on simple loop which draw chunks and fetches heights from heightfield, so I haven't implemented quadtree yet, though it's ready to go in and change whole code again (including complete change in rendering method). In most cases I was reading philip strugar paper about cdlod, additionaly researching his code. Well, at some point I had no power to go through morphs (possibly there was no quadtree implemented), so I decided to use skirts and it fulfills my needs for now. At the same time I've gathered some savage methods of texturing. For now I limit myself for 3 ground textures which is my next step in my journey through the complexity of terrain. I did consider making few rendering passes for more than 3-4 textures depending on chunk's needs or try to use textur[attachment=10797:screen.jpg]e-atlas. But, for now I'd like to know how may I set tiling factor/whatever to see the ground detailed from far distance and from close view point, in meanwhile keeping the transition between those levels. Even in strugar's demos it was clearly obvious that he adds detail (it makes smoothy effect when close anyway), but he didn't use many textures. I did the same, but it looks horrible when you enlarge grass tiling and add detail:P I can't mount overall color texture and use grass etc as detail textures but... yea but... maybe for few heightmaps it won't be horrible memory shock? Let's say the target is 64x64km map - would be enough I think. More, I think quadtree will blow performance down anyway... eh, to the point. I'm still interested in methods of texturing close/far viewpoints. The result I take now is visible on attached screenshot, it's tiling factor is set to approx 1 meter per quad, so from far distance looks like spilled jelly [img][/img] I want to see sharp mountains at distance and totally nice rocks from 3 meters, as in ideal terrain:P What would you advise?[img][/img] [attachment=10798:screen.jpg]
  3. Some good game design tips?

    From my 3-year experience of cloning 'a' common mmo I would say that... - if you're not composing a team and you want make things clear to you, just abandon horrible design patterns (except singletons maybe:P but you can support yourself with procedural techniques), cause they will mess and mess you until you completely understand them. Then you'll discover that you need more and more lines of code that could be never seen in future. The idea is to use as much oop as you need for base for the game, the rest bases on uber-total-entity object which handles every instance of the game, then use lua/whatever to control whole stuff. I came to that point after two rewrites, my code is still for me but at least I can handle all game logic with simple scripting routines. - if you're a team member, team creator then I would consider using some more oop concepts - if the game type excludes point one and two then I don't know:) Finally, summing up - after rewriting/simplifying things you'll find your own way, but it's good to know common oop patterns/paths. PS: Agile programming - under that term I used to learn many things:)
  4. Hello again! Till now processing r32f at vertex shader wasn't a big deal, but I decided to exlude bmp/jpg heightmaps from my project and replace them with dds version in r32f format, which allows my crappy gpu to do vtf. I spent some time trying to get proper values from this format and I'm still failing, even though I found lots of conversion methods. The msdn says that the most important is the red channel, but I don't really get it in terms of reading from lockedrect. I use standard method of reading data from texture - so each time I take four bytes and I don't really know how to decode it to proper black-white value. I used to take only red byte and it seemed aaaalmost ok, but there were some glitches on the output height-image. Could someone give me a clue how to take the brightness from these four bytes properly?
  5. Saving normals to texture.

    Bueh! Subject might be closed or deleted, useless problem... But before, could someone explain me why in FVF format NORMAL has to be before DIFFUSE? I found out that normal is saved in bgra format, but I was still missing one component, the Z, always equal to zero. So I remember I had problems with fvf before I tried to replace fvf and vertex data and suddenly the lost val has appeared. I can't believe it:P
  6. Saving normals to texture.

    When I'll be at home in six hours I'll make some additional shots and attach them. Regarding the byte order, I think I checked that already, in some cases swaping R with G was helping to obtain similar results, but still lacking blue:( If I won't fix it, I'll render to texture where I'll be certain that I pass proper vals:P EDIT: Ok, changed few things and situation is a bit different. There's a screenshot showing the state of normalmap and vertex normals. Here's some data got from mesh vertex buffer (in most cases vertex normals are close to 1,0,0): VERTEXNORMAL: 0.92, 0.29, 0.00 ENCODED: 0.96, 0.64, 0.50 (normal * 0.5 + 0.5) DECODED: 0.92, 0.29, 0.00 (fetchnormal * 2 - 1) TEXCOLOR: 244.76, 164.29, 127.50 (it goes to external texture file) VERTEXNORMAL: 0.55, 0.18, 0.00 ENCODED: 0.78, 0.59, 0.50 DECODED: 0.55, 0.18, 0.00 TEXCOLOR: 198.24, 151.06, 127.50 ... I don't really know in what space d3dxcompute calculates normals so they should point 0,1,0 instead of 1,0,0:P
  7. Yo there. I'm facing weird problem with my normals, so if someone finds a solution please share! Desc: I'm testing two identical grid-meshes, based on heightmap 256x256. One is computed at runtime in vertex shader, where height is taken through vft. The second one is generated on cpu with heights taken directly from texture data. Normals are generated with d3dxcomputenormals, so the second mesh is lit properly by simple diffuse directional light. For testing purposes I do output dx normals as colour, so I see nice green/red/magenta colours:) Next... All the normals from the cpu mesh were saved in texture (A8R8G8B8) in the form of: (vertexnormal * 0.5 + 0.5) * 255; Then, on the other side, deep in the VS I take them out with tex2D(norms,proper_coord) * 2 - 1; I checked encoding routine many times, assuring that proper channels are filled and still I can't get proper normals. They are almost the same, but I see the lack of blue/magenta colours. What I want to do is to just check the method of passing normals through texture and heck I don't see that invisible misstake or error:P From what I wrote, do you see things that might be destroying my results?
  8. Struggling with an items database

    I would remove this class and replace it with standard EntityItem class, which describes every possible object. It can be done by setting proper flags or string:var/prop system which is sufficient to describe almost all properties. Later you will obtain one class with no conflicts, it'll be easy for containers and with help of scripting language or callbacks you can achieve better results in less time. I give that point of view cause there were moments in my Cpp-life that multi-inheritance limited me hardly.
  9. Lua states confusion

    Thanks a lot! After implementation and some little fixes it works great. The only thing I left (and it seems working) is dofile every time a script is initialized. This is due to the fact there is an object creation at inheritFrom call. It registers every new object behind the scene so everything is set up properly when managing further calls from api, and even I managed to init scripts from within running scripts with unlimited level of depth:P How it will bounce off the performance, don't know, but thanks for a good advice. Problem solved. Might be closed.
  10. Lua states confusion

    Hello there. After digging deeply in previous subjects of that kind I came up to great confusion regarding lua states. There is certain scheme of my scripting vision, which I derived from lpmuds and which I want to translate to Lua, more or less. I managed to achieve similar result while using lua_state per entity basis, but what I've found out is a great amount of memory being absorbed when reaching high entity count. That have should be clear to me if I put my built-in functions to every state, forcing it to grow with huge impact! After few tests I came up to the point that I need one state for all the entities, but a whole bunch of problems appeared due to the shape of my scripting vision:P Maybe someone could help me solving this issue. Here's some overview to what I achieved with multiple states. Some pseudo code of LionClassLib and lion.lua [CODE] function LionClassLib:CreateLion() setting default values end; function LionClassLib:LionCallback() print("ROAR"); end; -- This function is called from c api -> every time a new entity is created function create_object() this():CreateLion(); -- this() -> returns current object table (defined through binding objects to uids in inherit.lua, apply only when trying to fight with one lua state, in case of many states this() will lead to base object, so this part works anyway) end; function do_anything() this():LionCallback(); end; -----> lion.lua <----- require "inherit" require "LionClassLib" LocalObject = inheritFrom(LionClassLib); -> sets metatables and returns table/object with class def and standard behavior function LocalObject:CreateLion() LionClassLib:CreateLion(); -- Setting the parent's constructor -- additional local stuff if needed end; [/CODE] While being on many states the great advantage was that I could call another object creation through C API and it didn't destroy globals of the current one. Now I can't, but this part I can omit. The idea behind many states was that I could lual_dofile every script, pass initial callbacks and it ran ok. Then I was able to call events from api the same way. But at this point I'll have the following problem: 1. Clone Entity 1 with lion.lua 2. Load script and call create_object (this():CreateLion) 3. Clone Entity 2 with monkey.lua 4. Load script and call create_object (this():CreateMonkey) 5. It's obvious it will be ok until next point:P 6. Clone Entity 3 with dofile lion.lua! CRASH: luadofile won't compile the same file, the last global create_object comes from monkey.lua where there is no function CreateLion. So, I hope the idea is quite clear. I was trying to play with environments with setfenv/getfenv etc but I'm not sure it's the right way. I can try with lua_state per script, then it might work, but I'm not quite sure if something wouldn't suddenly blow up. If someone could direct me in proper direction I'd be pleased. Thanks for reading.
  11. PIX speeds up my app

    Hello. Yesterday I've encountered a weird problem while debugging my application in DirectX environment. I was trying to render a big model (about 25-40k polys, 65550 verts, but I'm not sure right now). It's been rendered even on completely empty scene, where I found horrible loss of fps. Previously, when I was rendering smaller objects it wasn't harmful, but I suspect that all the things in my game give my card a nice performance shock. Next thing I did was to run it on better graphics card, everything was ok until I faced the big model, which affected performance again. It doesn't even matter whether the object is far far away or it's very close to the camera. I checked my particle system where I rendered around 60k polys at optimum distance (fillrate reasons) and I got much better results. Of course the closer the particles, the worst performance. But that damned model doesn't get into that rule. The model itself has 2048 uv-texture (with no texturing i get same things) and is rendered with one DrawSubset call. So, what does PIX say? It says that drawsubset calls drawindexedprimitive - so it's ok. I called drawindexedprimitive manually as well so I'm sure it doesn't use UP version. Now the main question - when I'm running my app from PIX I get performance hit and the game behaves normal. When I'm in pure debug/release mode I get 5-6 fps (old graph card) while facing bigger model and suddenly while in PIX I get 16-17 fps I see no terrible drop downs. Maybe someone know the relation of PIX and my app or some clues that could direct me to things that are messed up in my code. Thanks for reading/answering! SOLVED: Routine respoinsible for picking gave me a killing shot while intersecting huge meshes... Low poly mesh will be the solution.
  12. Common code for 2D and 3D games

    Make 2D game by using your 3D engine/utilities/wrappers. Love quads, buffers and triangles :) Making it in raw 2D with sprites etc would extend your engine for no reason.