My laptop should hopefully be able to handle this just fine. I can run MInecraft with far render distance and fancy graphics and still get about 90 FPS.
I started coding textures, and so far the code for textures is so bad and dull that I'll praise anyone who can fix it or make it better when I release the open-source version. So far I have it working, but face issues with render distance stuff and need to finish more textures.
(ignore the FPS counter in the title, it isn't accurate at all)
(near-infinite render distance + no fog = more lag than in MCPE)
If I remember correctly, MCedit changes the textures to really easy to render textures (1 color of green for the leaves block) if you get further away from the scenery. I'm sure this will increase the FPS. I don't know how to code that, because I'm not a pro in coding. Keep the good work going! It looks great already!
Nice! Will it be on the computer or do you think the tablets and phones can run it? I was talking to 500ise about stuff like this, but he said he didn't know much about it.
Nice! Will it be on the computer or do you think the tablets and phones can run it? I was talking to 500ise about stuff like this, but he said he didn't know much about it.
It's easy to use LWJGL or openGL in general, it's the same throughout all programming languages. I learned from a Youtube series made by "TheCodingUniverse" but there are other video series for different programming languages.
If I remember correctly, MCedit changes the textures to really easy to render textures (1 color of green for the leaves block) if you get further away from the scenery.
The point of MCPEWorldEdit is to look as much like Minecraft as possible. My current method of getting textures is flawed and I already know it, so that is why it is the reason it's slow. If someone offers a better solution, which could be done and doesn't require LWJGL experience to do, it would be much faster.
Rollback Post to RevisionRollBack
Did you know I make music? Just click my logo to listen to my awesome Electronic beats!
Once again, you really went over the top. Nice work! I think you should slow down on the projects tho. I don't want you spending all of your time working on these!
Once again, you really went over the top. Nice work! I think you should slow down on the projects tho. I don't want you spending all of your time working on these!
Nonsense, I have too much free time. School and people are too boring, programming is fun (sound like a real nerd :P).
Rollback Post to RevisionRollBack
Did you know I make music? Just click my logo to listen to my awesome Electronic beats!
Ha well just don't work too hard (unless it's fun, I like programming too)
Figuring out what random data means in hex editors is fun. Trying to figure out the code behind the programs you use everyday is fun. Solving the challenges you face in designing a program is fun. Trying to use all of those skills to create your own program is euphoric.
Figuring out what random data means in hex editors is fun. Trying to figure out the code behind the programs you use everyday is fun. Solving the challenges you face in designing a program is fun. Trying to use all of those skills to create your own program is euphoric.
I can't program my own tool, but I am still learning how to. I love to look into the files of other things I use every day and figure out how they work. It is just fun to change codes and see what you can do!
Mine runs on 9 It doesn't even let me create a new world. All I can play is red stone preset on tiny render, fast graphics, no smooth lightning, no Advance open GL, particles minimal. Still it lags ALOT. So I don't have a chance of playing on survival Good I didn't buy the account. Darow for test purposes
At least I know my laptop is a good one. I was not sure when I got it if it would run Minecraft well or not. BTW, when are you going to release open-source? I can't wait to see how this project turns out.
I started coding textures, and so far the code for textures is so bad and dull that I'll praise anyone who can fix it or make it better when I release the open-source version. So far I have it working, but face issues with render distance stuff and need to finish more textures.
(ignore the FPS counter in the title, it isn't accurate at all)
(near-infinite render distance + no fog = more lag than in MCPE)
In MCPE when there is no smooth lighting the sides of the blocks are shaded a bit to give a feel of orientation. All blocks facing north are a bit brighter, all blocks facing south are a bit dimmer, and so on. This could be a lag-free way of giving depth to the textures.
The point of MCPEWorldEdit is to look as much like Minecraft as possible. My current method of getting textures is flawed and I already know it, so that is why it is the reason it's slow. If someone offers a better solution, which could be done and doesn't require LWJGL experience to do, it would be much faster.
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.
Rollback Post to RevisionRollBack
Did you know I make music? Just click my logo to listen to my awesome Electronic beats!
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.
Rollback Post to RevisionRollBack
Did you know I make music? Just click my logo to listen to my awesome Electronic beats!
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
If I remember correctly, MCedit changes the textures to really easy to render textures (1 color of green for the leaves block) if you get further away from the scenery. I'm sure this will increase the FPS. I don't know how to code that, because I'm not a pro in coding. Keep the good work going! It looks great already!
Proud to be a M.C.P.E.U member
Umm, is there something wrong with that?
It's easy to use LWJGL or openGL in general, it's the same throughout all programming languages. I learned from a Youtube series made by "TheCodingUniverse" but there are other video series for different programming languages.
The point of MCPEWorldEdit is to look as much like Minecraft as possible. My current method of getting textures is flawed and I already know it, so that is why it is the reason it's slow. If someone offers a better solution, which could be done and doesn't require LWJGL experience to do, it would be much faster.
Click on an image to view the section rules!
Nonsense, I have too much free time. School and people are too boring, programming is fun (sound like a real nerd :P).
Ha well just don't work too hard (unless it's fun, I like programming too)
Click on an image to view the section rules!
Figuring out what random data means in hex editors is fun. Trying to figure out the code behind the programs you use everyday is fun. Solving the challenges you face in designing a program is fun. Trying to use all of those skills to create your own program is euphoric.
I can't program my own tool, but I am still learning how to. I love to look into the files of other things I use every day and figure out how they work. It is just fun to change codes and see what you can do!
Click on an image to view the section rules!
At least I know my laptop is a good one. I was not sure when I got it if it would run Minecraft well or not. BTW, when are you going to release open-source? I can't wait to see how this project turns out.
In MCPE when there is no smooth lighting the sides of the blocks are shaded a bit to give a feel of orientation. All blocks facing north are a bit brighter, all blocks facing south are a bit dimmer, and so on. This could be a lag-free way of giving depth to the textures.
How do you currently handle the textures?
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