The new features look pretty cool. I see why Turbo is taking his time with the update — it's not strictly just for compatibility.
If there was a way to custom-scale GUI elements, including the item hotbar, to something other than "small, medium, large, scale to GUI" in a very granular fashion with maybe like a slider of some sort, that in itself would make this mod a must-have for any respectable Minecraft player.
I'm actually currently toying around with that idea. Here's what it looks like:
With nearest interpolation (Minecraft default):
With linear interpolation:
As you can see both examples produce horrible results. In order to get it to work in any decent way I'd need a 1 pixel gap in between all the sprites in the texture. I'd have to write something that will copy the icons to it's own texture every time the texturepack changes.
I can probably explain why this next update is taking so long...
The recent Minecraft Version added more options with the chat box and this screwed up the compatibility with a lot of class files.
That's why this next update is taking such a long time.
I hope this answers the question everyone is asking...
No, I'm actually recoding the mod from scratch. Don't worry, it'll be worth it, you'll see.
I'm actually currently toying around with that idea. Here's what it looks like:
With nearest interpolation (Minecraft default):
With linear interpolation:
As you can see both examples produce horrible results. In order to get it to work in any decent way I'd need a 1 pixel gap in between all the sprites in the texture. I'd have to write something that will copy the icons to it's own texture every time the texturepack changes.
they both look fine haha the bottom one is sharper but a bit fuzzy
The pixels in the top one are skewed. This will be even more noticeable when you shrink it, as some pixels even start to disappear.
The bottom on has pixels from the sprites next to it bleeding trough on the edges. If you look at the hunger bar you can even see some pink from the placeholder texture.
The top one looks fine. I don't see an issue. If there's a specific size where pixels would be lost, maybe that should be defined as the minimum threshold for the smallest size setting. Since resizing the window running JVM where Minecraft resides in turn resizes the GUI elements, I assumed maybe there's a way to scale the GUI elements using some artificial boundaries instead of the full window size to more or less achieve custom sizes. Then again, I've never in my life written anything with a GUI, let alone a game that made use of sprites, so I have no idea.
The top one looks fine. I don't see an issue. If there's a specific size where pixels would be lost, maybe that should be defined as the minimum threshold for the smallest size setting. Since resizing the window running JVM where Minecraft resides in turn resizes the GUI elements, I assumed maybe there's a way to scale the GUI elements using some artificial boundaries instead of the full window size to more or less achieve custom sizes. Then again, I've never in my life written anything with a GUI, let alone a game that made use of sprites, so I have no idea.
Do you mean GUI or OpenGL / DirectX?
My current plan of attack is to create a new texture in memory, then copy and upscale the icons to it.
Then, whenever the scale is an integer, I'll set the texture filtering to nearest (so it looks crisp, like default). And whenever the scale is a point number I'll set the filtering to linear. The result is a sprite that, because of the upscaling, isn't as blurry as the example above. It's a crude method of anti aliasing really.
This will also allow me to clean up the locations of the icons on the texture which will result in only having to pass 1 set of coordinates to the renders for the icon strips (instead of 3 sets; full sprite, half sprite, background).
ah i understand this a bit :3 thanks for that one c++ class XD what would the data and logic be?
If we take the healthbar as example, the data would be:
- The total amount of hearts to render.
- The the amount of filled hearts.
- the transparency.
- a flag for if the bar should flash.
- a flag for hardcore mode.
- the poison effect.
- the wither effect.
- the wiggle effect.
- the regen effect.
Logic means how the data is calculated. For example; in the case of the transparency value, if the health bar is set to fade, the value will be calculated based on what is happening (the player taking damage or not) and the settings (fade speed, fade threshold).
Ready for the kicker? The "Settings for Healthbar" menu is also a view.
The logic (model) gets calculated every Minecraft tick (rate of 20 times/second). The health bar gets rendered every single frame (rate of fps/second).
When Minecraft renders, I only have call the associated display list (an OpenGL feature) instead of calculating everything every frame (vanilla Minecraft).
Result: FPS increase at the cost of Memory usage increase + all other benefits of MVC, like customizability.
If we take the healthbar as example, the data would be:
- The total amount of hearts to render.
- The the amount of filled hearts.
- the transparency.
- a flag for if the bar should flash.
- a flag for hardcore mode.
- the poison effect.
- the wither effect.
- the wiggle effect.
- the regen effect.
Logic means how the data is calculated. For example; in the case of the transparency value, if the health bar is set to fade, the value will be calculated based on what is happening (the player taking damage or not) and the settings (fade speed, fade threshold).
Ready for the kicker? The "Settings for Healthbar" menu is also a view.
The logic (model) gets calculated every Minecraft tick (rate of 20 times/second). The health bar gets rendered every single frame (rate of fps/second).
When Minecraft renders, I only have call the associated display list (an OpenGL feature) instead of calculating everything every frame (vanilla Minecraft).
Result: FPS increase at the cost of Memory usage increase + all other benefits of MVC, like customizability.
wonderful XD hahaha i feel as though something that does that much logical calculations per tick will lower the fps dramatically because so much is happening at once... we will just have to wait and see
no matter what the outcome, i know that your very helpful HUD will always be number one in my book
Increasing the fps isn't the outset of the mod though. So I doubt it'll be noticeable, unless you measure it. It's just a nice bonus to this whole MVC system.
Wow, this update is getting pretty intense. So it's now going to decrease the computational overhead for rendering the HUD and give us a couple extra FPS.
I've probably said this before, but anyway, here's a little nice idea for Advanced HUD: Numbered replacements for certain GUI items. So you can see your health much clearer, Counter-Strike/Half Life style! And it can optionally be set in percentages (100% health=10 hearts/whatever HUD element), or in default (20 health=10 hearts/whatever HUD element).
I've probably said this before, but anyway, here's a little nice idea for Advanced HUD: Numbered replacements for certain GUI items. So you can see your health much clearer, Counter-Strike/Half Life style! And it can optionally be set in percentages (100% health=10 hearts/whatever HUD element), or in default (20 health=10 hearts/whatever HUD element).
i'm starting to think Turboslow never updates, Every update seems to mean 'time for an overhaul!'
I'm on to you, re-doing your mod all the time, making it twice as amazing just because you just can't be bothered updating it.
Rollback Post to RevisionRollBack
"why didn't i do that? because that would make sense."
i'm starting to think Turboslow never updates, Every update seems to mean 'time for an overhaul!'
I'm on to you, re-doing your mod all the time, making it twice as amazing just because you just can't be bothered updating it.
Haha, that's kinda true. I do update every now and again though. What I like about programming is learning new stuff every time, then applying that new knowledge to your projects and making them better with each iteration.
Hey turbo, soon i am going to be working on a minecraft series and i think this mod would go really really well with the "Damage indicators" mod but i was just wondering when you were planning on updating? and i was also wondering if you could release an update of the normal mod, just so that we could have something, while we are waiting on the "overhaul"
With linear interpolation:
No, I'm actually recoding the mod from scratch. Don't worry, it'll be worth it, you'll see.
Advanced Hud
http://www.minecraft...0#entry19843543
Advanced Hud
they both look fine haha the bottom one is sharper but a bit fuzzy
The bottom on has pixels from the sprites next to it bleeding trough on the edges. If you look at the hunger bar you can even see some pink from the placeholder texture.
Advanced Hud
My current plan of attack is to create a new texture in memory, then copy and upscale the icons to it.
Then, whenever the scale is an integer, I'll set the texture filtering to nearest (so it looks crisp, like default). And whenever the scale is a point number I'll set the filtering to linear. The result is a sprite that, because of the upscaling, isn't as blurry as the example above. It's a crude method of anti aliasing really.
This will also allow me to clean up the locations of the icons on the texture which will result in only having to pass 1 set of coordinates to the renders for the icon strips (instead of 3 sets; full sprite, half sprite, background).
Advanced Hud
-
View User Profile
-
View Posts
-
Send Message
Curse Premium(image source: http://www.moock.org/lectures/mvc)
For example the solid bar and the icon strip are 2 different views that I can apply on any of the health, food, armor or air bars.
/developertalk
Advanced Hud
ah i understand this a bit :3 thanks for that one c++ class XD what would the data and logic be?
If we take the healthbar as example, the data would be:
- The total amount of hearts to render.
- The the amount of filled hearts.
- the transparency.
- a flag for if the bar should flash.
- a flag for hardcore mode.
- the poison effect.
- the wither effect.
- the wiggle effect.
- the regen effect.
Logic means how the data is calculated. For example; in the case of the transparency value, if the health bar is set to fade, the value will be calculated based on what is happening (the player taking damage or not) and the settings (fade speed, fade threshold).
Ready for the kicker? The "Settings for Healthbar" menu is also a view.
The logic (model) gets calculated every Minecraft tick (rate of 20 times/second). The health bar gets rendered every single frame (rate of fps/second).
When Minecraft renders, I only have call the associated display list (an OpenGL feature) instead of calculating everything every frame (vanilla Minecraft).
Result: FPS increase at the cost of Memory usage increase + all other benefits of MVC, like customizability.
Advanced Hud
wonderful XD hahaha i feel as though something that does that much logical calculations per tick will lower the fps dramatically because so much is happening at once... we will just have to wait and see
no matter what the outcome, i know that your very helpful HUD will always be number one in my book
Advanced Hud
I like it.
I'm on to you, re-doing your mod all the time, making it twice as amazing just because you just can't be bothered updating it.
Haha, that's kinda true. I do update every now and again though. What I like about programming is learning new stuff every time, then applying that new knowledge to your projects and making them better with each iteration.
Advanced Hud