Improved speed immensely! Before, a render radius of 50 (which isn't very far) caused massive lag the farther you get to the center of the world. Now, the viewing radius is unlimited, but still will not lag your computer. You can change the viewing radius (a.k.a. render distance) to be what ever you want, but no matter what you set it to I can almost promise it will not lag at all.
There are two last steps to this program until I will release the beta viewer version. First is finishing textures, which is just programming every side of every block so the program knows what texture to render on each block on each side. Second is lighting, which is the biggest thing I have problems with. Since LWJGL isn't as simple as "If you place sun here, shadows and light will appear," I have to come up with a way to light the surface of every block according to their data in the chunks.dat and according to data from LWJGL itself. Lighting is the hardest thing, but it's what makes the world 3D, without lighting it just looks like a bunch of textures mixed together in a 2D, flat image. I might even release the world viewer first without lighting, and then figure it out later.
Anyway, I'm making progress, and I have not just posted this for you all to say "WOW" and never release, it's just difficult when you run into issues you never expected to happen.
I have methods in a "Textures.java" class that define the location of each texture for each of the 6 sides in a block. When the world is first loaded, all the textures are matched with the corresponding block and each new Block class is initialized with a 2D array containing 6 arrays with each textures X&Y start points in the terrain.png. It's faster than it might sound, and going from loading to rendering is only 1.2 seconds at most for my computer. The only sad thing is though, I only initialize visible blocks at first, otherwise loading could take up to 4 minutes; so all other blocks are seen as "null" until otherwise stated different.
To reduce lag, only visible sides of blocks are shown, and I also cull (make invisible) the backsides of the cube faces to also reduce lag. I would like to implement a frustum culler to reduce lag the further towards the center of the world you go, but I haven't figured that out yet.
You could do it like Minecraft, where every block extends the "Block" class, and is initialized with the texture for it when the program starts. That way every time you create a new instance of that block you aren't loading the texture too. If it loads a chunk at a time that's 32 678 textures you didn't need to load into memory
You could do it like Minecraft, where every block extends the "Block" class, and is initialized with the texture for it when the program starts. That way every time you create a new instance of that block you aren't loading the texture too. If it loads a chunk at a time that's 32 678 textures you didn't need to load into memory
Good idea
Rollback Post to RevisionRollBack
"It's not what your country can do for you, it's what you can do for this country."
You could do it like Minecraft, where every block extends the "Block" class, and is initialized with the texture for it when the program starts. That way every time you create a new instance of that block you aren't loading the texture too. If it loads a chunk at a time that's 32 678 textures you didn't need to load into memory
I didn't want to mess around with chunk loading radius, so I just load every block at once but render only visible faces in the render distance radius using LWJGL's stock render distance code, then use fog to get rid of bad looking edges of the map. The whole world file is already going to be in the memory anyway so later-on I can provide up-to-date edits to the file (and automatically save a backup and undo array if you don't like your edits).
Rollback Post to RevisionRollBack
Did you know I make music? Just click my logo to listen to my awesome Electronic beats!
I didn't want to mess around with chunk loading radius, so I just load every block at once but render only visible faces in the render distance radius using LWJGL's stock render distance code, then use fog to get rid of bad looking edges of the map. The whole world file is already going to be in the memory anyway so later-on I can provide up-to-date edits to the file (and automatically save a backup and undo array if you don't like your edits).
I see, if it's all loaded at once, might as well do the extra heavy lifting to make it run smoother during user interaction. Well, as long as you have that figured out Have you tried implementing the method I suggested earlier to add depth to the textures? I'm sure it wouldn't be too much of a hassle, unless you plan to use smooth shading instead
Have you tried implementing the method I suggested earlier to add depth to the textures? I'm sure it wouldn't be too much of a hassle, unless you plan to use smooth shading instead
I eventually want to move to adding a class for each block, but that takes forever (and there is only one of me), and everything can be simplified right now without needing all of that. Later when I add interactivity and individual functions to blocks, I'll make a new class for every single one, but that's just later. For now, I don't even need to know anything about the block except it's ID to do anything from texturing to shape and finally rendering.
As for smooth shading...probably would be easier to implement right now than the block-by-block shading Minecraft has.
Anyway, I will release a test version soon, once I get transparent textures (like saplings, glass and flowers) done. Right now all transparent pixels are black.
Nice job, looking forward to this
Also, slightly off-topic, but if you do make an update for iMCPEedit, could you find a way to remove the dependency on iOS 5 or higher?
I eventually want to move to adding a class for each block, but that takes forever (and there is only one of me), and everything can be simplified right now without needing all of that. Later when I add interactivity and individual functions to blocks, I'll make a new class for every single one, but that's just later. For now, I don't even need to know anything about the block except it's ID to do anything from texturing to shape and finally rendering.
As for smooth shading...probably would be easier to implement right now than the block-by-block shading Minecraft has.
Anyway, I will release a test version soon, once I get transparent textures (like saplings, glass and flowers) done. Right now all transparent pixels are black.
Cool! Well, if you need any help, post it here. I'd be glad to help out a little
It summarizes the number of lines and characters in any unicode file, counts the number of files/sub-directories within a directory, and displays a preview of said file/directory.
But, I'm a perfectionist, and there are soo many things wrong with the rendering code. First, back side of faces render, adding unnecessary lag (game slows but frame rate doesn't) to something you can't see. Second, two sides of transparent blocks are "glitchy" in that blocks behind them don't show.
But, I'm a perfectionist, and there are soo many things wrong with the rendering code. First, back side of faces render, adding unnecessary lag (game slows but frame rate doesn't) to something you can't see. Second, two sides of transparent blocks are "glitchy" in that blocks behind them don't show.
Does it render all faces visible to the player, or just the visible ones that aren't obscured by other blocks?
-
View User Profile
-
View Posts
-
Send Message
Retired StaffYou could do it like Minecraft, where every block extends the "Block" class, and is initialized with the texture for it when the program starts. That way every time you create a new instance of that block you aren't loading the texture too. If it loads a chunk at a time that's 32 678 textures you didn't need to load into memory
Good idea
I didn't want to mess around with chunk loading radius, so I just load every block at once but render only visible faces in the render distance radius using LWJGL's stock render distance code, then use fog to get rid of bad looking edges of the map. The whole world file is already going to be in the memory anyway so later-on I can provide up-to-date edits to the file (and automatically save a backup and undo array if you don't like your edits).
I see, if it's all loaded at once, might as well do the extra heavy lifting to make it run smoother during user interaction. Well, as long as you have that figured out
I eventually want to move to adding a class for each block, but that takes forever (and there is only one of me), and everything can be simplified right now without needing all of that. Later when I add interactivity and individual functions to blocks, I'll make a new class for every single one, but that's just later. For now, I don't even need to know anything about the block except it's ID to do anything from texturing to shape and finally rendering.
As for smooth shading...probably would be easier to implement right now than the block-by-block shading Minecraft has.
Anyway, I will release a test version soon, once I get transparent textures (like saplings, glass and flowers) done. Right now all transparent pixels are black.
Also, slightly off-topic, but if you do make an update for iMCPEedit, could you find a way to remove the dependency on iOS 5 or higher?
My Pocket Edition Mods:
Gravity Gun
[Follow me on twitter]
While your waiting, make this program yourself.
One does not simply make a Program
Look, your complaining because your impatient, I just tried suggest a better alternative.
(Can you make it so the entities.dat gets displayed two (even edit signs^^))
I could try to help though!
Proud to be a Miner...
Cool! Well, if you need any help, post it here. I'd be glad to help out a little
LOL!
+1 to you good sir.
EDIT:
I did today :/
It summarizes the number of lines and characters in any unicode file, counts the number of files/sub-directories within a directory, and displays a preview of said file/directory.
try it.
Me too!
But, I'm a perfectionist, and there are soo many things wrong with the rendering code. First, back side of faces render, adding unnecessary lag (game slows but frame rate doesn't) to something you can't see. Second, two sides of transparent blocks are "glitchy" in that blocks behind them don't show.
-
View User Profile
-
View Posts
-
Send Message
Retired StaffDoes it render all faces visible to the player, or just the visible ones that aren't obscured by other blocks?