Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[JamesPlotts]

Too bad it's in VB. I'm sure there's a heck of a ton more, say, C-inspired language users^* than VB.



*C, C#, C++, Java ...

Well, have written VB all my life and can speed-read it whereas C++/C# is like Japanese to me.

I decided to bite the bullet and port what I've got to C# in the hopes of attracting helpers. 

I am also going to move the project over to codeplex.com.

[JamesPlotts]

I decided to bite the bullet and port what I've got to C# in the hopes of attracting helpers. 

I've actually done some thinking about this and have decided on a hybrid project.  I will do the core game logic in a VB.NET DLL library to leverage the RAD features of that language, and I will use C# to wrap it with the graphics logic so as to take advantage of the much better XNA Content compiler for graphic resources. 

Too bad it's in VB. I'm sure there's a heck of a ton more, say, C-inspired language users^* than VB.

Its kinda funny as no one has expressed interest in helping with the project.

[Girlinhat]

I wouldn't do this with thoughts/ambitions of getting donations, especially if you're not going to contribute any original ideas into the design. A straight clone of DF is all well and good, but at the end of the day, Toady and ThreeToe are the only people who should get money for their ideas.

So, should the people at Chrysler and GM not get paid for Henry Ford's ideas?  If Toady and ThreeToe had made a 3D dwarfy sand-box game, then yeah, I agree with you (and this conversation would never had taken place).  However, ideas are not protected.  Only their presentation.

If they were making the Model T with a modern engine, then yes there's an issue.  Since you blatantly said "I'm going to copy DF as accurately as I can" then yeah.  If you said "I'm gonna make something DF-inspired but change some things for balance" then you're doing your own thing.

[Imofexios]

How accuarte 3d Modeling you need?
I could be interested helping in 3d art modeling once i get my new PC scrapped up.
It sounds you really need help on coding such a big project

[JohnieRWilkins]

If they were making the Model T with a modern engine, then yes there's an issue.  Since you blatantly said "I'm going to copy DF as accurately as I can" then yeah.  If you said "I'm gonna make something DF-inspired but change some things for balance" then you're doing your own thing.

People tend to say things they don't mean/don't make any sense/are the exact opposite of true. An open source project has 0% chance of being a perfect DF clone unless its sole contributor is some person who doesn't give a crap about the end result. Humans aren't robots and can't copy something concept-for-concept without having at least some personal creative input. It doesn't happen unless bureaucracy is involved.

[Dokkir]

Good luck man, I'm rooting for you!

[JamesPlotts]

Well, I have to admit that this is not a feasable project, in terms of processing power of present day PC's. 

After working up the necessary logic to create some terrain in an array of 255x255x255 locations, with an average of 190k drawable ground blocks, it takes a considerable amount of time (+2 seconds) to render a frame in the 3D viewport using XNA.  I could probably cut the number of visible blocks by about half, but the game would still have other objects like trees, boulders, buildings, dwarves, etc.  People who want a 3D game would expect smooth panning and scrolling, and probably would be quite disappointed.

Perhaps if someone wanted to attempt this in C++, they might have better success.

[Anvilfolk]

If the terrain remains relatively static, there's tons of optimisations you can do. I've avoided XNA because it's Windows-only, but I think it can be low-level enough that you have access to vertex buffers and the like? Besides, I don't think you're supposed to draw most things, only those that you can see. I mean, Minecraft renders more than 255*255*255 and uses Java, right?

[alexandertnt]

Well, I have to admit that this is not a feasable project, in terms of processing power of present day PC's. 

Some form of data-structure should massively speed rendering and physics up. Voxels are particularly easy and fast to manage. For example: http://en.wikipedia.org/wiki/Octree

Another algorithm (whose name I forget) based on hashing positions to array indexes would give a continuous time complexity (doubling terrain would make no change to render speed), that is you could have as many blocks as you have RAM and it would run just fine.

If the source is available, I might implement it myself.

[JamesPlotts]

Okay, I have some success now.  I got some terrain generating using perlin noise in the core and the wrapper is displaying it:



I was having some trouble and had to go back to my original project and copy some code that had been messed up with my experimenting.

[JamesPlotts]

Just posted R7 source code to the http://code.google.com/p/eighth-dwarf/ site.  This release has "WASD" key movement and "QE" rotation, and also a pickaxe cursor.  It lets you move around the map pretty nicely.

Also has text showing camera location and angle. 

I am having a problem with certain orientations drawing further location blocks on top of nearer blocks.  Does anyone have any suggestions as to how to fix that?

Next I will add location block "picking" ... i.e. selection.  I had it in the VB-only version, so should not take long to implement.

[GalenEvil]

@alexandertnt: Octrees are good for some things but for this application they can cause some slowdowns. I am working on a voxelized display engine myself and did octrees as a first POC. It ran very slowly since position lookups will be dependent on the depth of the tree. I haven't implemented a hashing function yet, but being constant-time lookups is a very useful feature of them.

@JamesPlotts: If you have constantly sized groups of blocks (chunks) that are some exponential value of 2 in size then you can use: (world location_xyz) and use a shift "<<"/">>" operator (cant remember which at the moment. Medicine suuuucks!) to get the world chunk location_xyz. From there you can get the position within the chunk via the & operator. Using bit-shifting operators is a small optimization over using division and modulus operators but can shave a lot of time from your mesh generation since the lookups get used upwards of millions of times over the course of runtime.
Also, I haven't used XNA but if you have questions about C# and specifically implementing things into your voxely world then hit me up If I don't know the answer I to a question I can probably logic it out. Good luck with this

[alexandertnt]

@alexandertnt: Octrees are good for some things but for this application they can cause some slowdowns. I am working on a voxelized display engine myself and did octrees as a first POC. It ran very slowly since position lookups will be dependent on the depth of the tree. I haven't implemented a hashing function yet, but being constant-time lookups is a very useful feature of them.

The Octree was the closest thing I could remeber the name of. I have implemented a hashing function like I described in my own project and memory/loading-times are now the limits. I know it has a name and a useful wikipedia article, but I just can't remeber the name of it, really fustrating. Something to do with constant sized grids.

I am having a problem with certain orientations drawing further location blocks on top of nearer blocks.  Does anyone have any suggestions as to how to fix that?

I had a quick look through the rendering code and you are using SpriteBatch and it looks like you are not setting any GraphicsDevice stuff back when you are done. SpriteBatch changes some rendering options (such as setting disabling DepthStencilState) when you call Begin()

This might be useful: http://gamedev.stackexchange.com/questions/31616/spritebatch-begin-making-my-model-not-render-correctly

[JamesPlotts]

I am having a problem with certain orientations drawing further location blocks on top of nearer blocks.  Does anyone have any suggestions as to how to fix that?

I had a quick look through the rendering code and you are using SpriteBatch and it looks like you are not setting any GraphicsDevice stuff back when you are done. SpriteBatch changes some rendering options (such as setting disabling DepthStencilState) when you call Begin()

This might be useful: http://gamedev.stackexchange.com/questions/31616/spritebatch-begin-making-my-model-not-render-correctly

Yes!  That fixed the ZOrder problem.  Thank you!

@JamesPlotts: If you have constantly sized groups of blocks (chunks) that are some exponential value of 2 in size then you can use: (world location_xyz) and use a shift "<<"/">>" operator (cant remember which at the moment. Medicine suuuucks!) to get the world chunk location_xyz. From there you can get the position within the chunk via the & operator. Using bit-shifting operators is a small optimization over using division and modulus operators but can shave a lot of time from your mesh generation since the lookups get used upwards of millions of times over the course of runtime.

My objects are sized at 300x300x300 in world space.  But it is now running quite fast.  At present I am drawing only explored and visible (topmost layer) objects.  Your implementation is intriguing and I will remember it for if things start bogging down.

Also, I haven't used XNA but if you have questions about C# and specifically implementing things into your voxely world then hit me up If I don't know the answer I to a question I can probably logic it out. Good luck with this

I appreciate this. 

I have split my project up into two portions like I said.  I have done this for several reasons. 

The first part is the core game Engine, which will contain all the 8th Dwarf game logic, to include loading and saving.  It is written in a VB.NET Library DLL.  I have done this as I wish to retain control over its implementation.

The second is the 3D interface wrapper application in C#.  I have put this out in the opensource arena in the hopes of finding someone willing to help in this area, and to show game developers how to interface with my DLL.  I figure this way, anyone could write their own game interface without duplicating the engine work. 

I also put the 3D stuff over in C# as the XNA support for 3D objects is much better in Visual C# than Visual Basic.

Theoretically, a particularly brilliant individual/group could write a multiplayer game on top of the DLL.

XNA lets me import FBX objects to use in 3D.  Right now I am scrounging for 3D objects as I am pretty much using free software to write the game.  I am using the Express editions of Visual Basic/C#, and Google Sketchup for my 3D objects.  I almost secured a full MSDN site license but that looks like a no-go now.  Do you have any suggestions for some decent 3D models/software on the free side?  Until I get some donations, that's what I have to work with.

[GalenEvil]

Blender is a decent free 3D modeling software and allows for exporting to FBX and many other common formats. Another, more aged but also free, is DAZ 3D which can be found here though I am not experienced enough with it to say whether or not you can export to FBX. Blender is a little unwieldy to use at first but it has a very large userbase and a number of tutorials for accomplishing your goals.

If you plan to have an infinite world or one that is truly massive in scale where you want to be able to render very large expanses at the same time then dynamic loading and unloading of 'chunks' from and to the disk is useful since it allows you to keep as little stored in RAM as is needed to render the immediately visible and a small buffer to reduce any serialization lag.

300x300x300 is a good amount to be rendering, and glad to hear that you have the visible-face-only rendering set up (I have had to walk many through the steps to implementing this). Are you planning to have caves? Looking at your Simplex source it looks like you could easily implement it. I would sample the Simplex noise at a larger step than 1:1, suggested values of between 4:1, 8:1, and 16:1 to get consistent and varied caves, and then interpolating discretely at 1:1 to smooth the inside of the caves so they do not show as large blocks but instead as something more cavelike.

How are you storing your voxel locations? And are you storing Voxel-specific information such as the type (dirt, sand, stone, etc)? Also, if you are currently implementing a variety of terrains are you using individual textures or a texture atlas?