Cool to see it going well. Thought i was screwed because vulkan support after the last video, but seeing all that... Yeah, oof. Well, gl on with the project
Here is a short overview. If you want to know it in more detail, you can take a look at the code itself: github.com/PixelGuys/Cubyz/tree/master/src/cubyz/rendering/text Under the hood I'm using java.awt.font.TextLayout for handling the glyphs and glyph positioning. To make it pixel-art I'm rendering the glyphs to a low-res BufferedImage without anti-aliasing. That BufferedImage is then used as a texture for openGL. Using openGL would theoretically allow me to also draw text in 3d. For the markdown stuff I'm using a simple parser that produces "markers" that are used for rendering. The bold text is simply drawing the texture 4 times with some offsets. Italic text is done by slightly shifting the top vertices of each glyph.
@@ricardoalcantara5846 I just did my font and UI rendering yesterday and it's much simpler, all you need to do is make a new pipeline for the ui, use orthographic projection for it, don't use the view matrix, turn off depth testing and backface culling for good measure, and then make the quad meshes for each letter sized accordingly to the pixel dimensions of the texture being used, that way, one pixel of the texture will equal one pixel on your screen, and from there it can be transformed and scaled or moved however just like any other mesh, the only difference is its position is now effectively 2D and correlates with the pixels on your screen, vec2(0,0) being the bottom left corner.
note that these are _not_ reasons that rewriting is bad (rewriting in itself is _never_ bad - the main issue is the time it takes to rewrite tbh) the issue is making decisions that made rewriting harder
I think the main problem is the reason for the rewrite. If like in my case the reason is "A lot of the code isn't designed to work with xyz" or "the codebase is ugly", then a rewrite from scratch is a bad idea. A partial rewrite or refactor is always the better choice because it allows reusing the code that works fine.
@@quantumdeveloper2733 i beg to differ... tl;dr generally "A lot of the code isn't designed to work with xyz" or "the codebase is ugly" are _excellent_ reasons to rewrite from scratch. especially if you consider the project as early in development. it's a lot better than rewriting a much more massive project because it absolutely needs one, and failing even harder (and just giving up on rewriting ever again, so you're just left with something subpar and there's nothing you can do about it) tl;dr2 from failing at rewriting you gain experience (mistakes are the best way to gain experience!), and that will almost certainly make the code you write in the future better, even if it doesn't seem like it "a lot of the code isn't designed to work with xyz" - it depends how you can make it work imo. e.g. sometimes you'll need to do a really hacky workaround, and... enough hacky workarounds and it'll quickly become unmaintainable "the codebase is ugly" - generally for me that means you have to essentially fully rewrite it anyway. so if the structure could be improved too might as well do that. that said, as i implied (?) in the original comment - it doesn't necessarily make a rewrite automatically smooth sailing. basically, doing things _differently_ doesn't mean doing things _right_. of course it's a good learning experience slightly offtopic, re: the thing with till++... seems mostly like team communication issues honestly. idk if it's too late or what but could try trello (= github project boards) and/or hackmd (~= a roadmap doc/other documents on the repo) and/or whatever to get everyone on the same page. this is especially important when making _huge_ changes since, well, _you_ will know the changes and therefore still be used to the codebase. but everyone else will have to read through the new code and become familiar with it. but also (as with the issue you had) sometimes they may just catch some issues (or non-issues?) you may not have caught
@@5omebody I can mostly agree with that. (You are especially right about the communication) But from my experience when saying "A lot of the code isn't designed to work with xyz", most of the code is actually fine. In my example modules like world generation, world saving, blocks, tools, GUI, rendering were mostly uneffected by multiplayer and only a few lines of these refer to stuff that is inaccessible in multiplayer. So there is really no reason to rewrite these parts. And about "the codebase is ugly": I too thought that this is a good reason to rewrite a project, and for small projects or early in development it definitely is, until I read this article: www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
@@quantumdeveloper2733 re: "most of the code is actually fine." - well this is going to sound a bit bad but... then that just means the statement "A lot of the code isn't designed to work with xyz" is just false, right? so the issue is _not_ that "code doesn't work with xyz", so if it's not a reason at all then it couldn't possibly be a _good_ reason tl;dr re: "small projects or early in development" - i'm pretty sure this counts as "small" (= under 100k lines) _and_ "early in development" (= few features). re: the article. firstly, that was written in 2000. practices have changed a lot since then (esp. testing practices). tools (e.g. programming languages) have changed a lot since then. tl;dr2 the article is _exclusively_ about commercial software - you can read through it again and try to note down where it mentions commercial stuff. so without time pressures, a lot of those issues already become non-issues secondly that mostly applies for huge pieces of software that has already been released, has a huge userbase, must maintain 100% backwards compatibility etc. these points will be based on points from the article: thirdly... re: "you probably don’t even have the same programming team that worked on version one" - was there even that much development before you joined? not to mention, assuming your foremost priority is _not_ sales, there is _nothing_ wrong with making mistakes - in fact, what you learn from the mistakes will be _the most valuable takeaway_ from this project. fourthly, see the conclusion of the article: "The old mantra build one to throw away is dangerous when applied to large scale commercial applications." note in particular *_large scale commercial applications_* - if it's neither large scale (for now) nor commercial (for now) then the article just completely doesn't apply in the first place.
Hi there ;D Actually I learnt the basics through Cubyz. When I joined it already had some graphics and over time I learned to work with what was there. And later I had enough knowledge of openGL, to work with the API directly. But to answer your actual question: learnopengl.com is a pretty good website for learning. I still use it for more advanced concepts.
@@quantumdeveloper2733 personally don't have any issues with compile times, and i think the added safety is well worth it, bit zig is a good choice too
Could. Not do for Minecraft, written java on PC and c++ on consoled. Makes difficult for parity and bugs for both and they’re what customers to swirtch to bed orck.
absolutely based in understanding how frustrating multi-platform support with C++ can be 😭
Quantum, you're an absolute legend. I hope you're going well in life. What you're doing here is amazing.
Absolutely amazing :D
Love the work you did there, the lod chunks are especially well done.
Game looks stunning too!
Very well put together video, looks like something that'd have atleast a couple hundread thousand views
Cool to see it going well. Thought i was screwed because vulkan support after the last video, but seeing all that... Yeah, oof. Well, gl on with the project
Heh, GL can stand for "good luck", but it can also be "Graphics Library" as in OpenGL.
Rewrite, lol. The vulkan world is a whole different level of pain
How do you have such a small amount of subscribers, your project is awesome
This LoD looks so goood.
Awesome video, lesson learned! I also got amazed with your font rendering, how have you done that?
Here is a short overview. If you want to know it in more detail, you can take a look at the code itself: github.com/PixelGuys/Cubyz/tree/master/src/cubyz/rendering/text
Under the hood I'm using java.awt.font.TextLayout for handling the glyphs and glyph positioning.
To make it pixel-art I'm rendering the glyphs to a low-res BufferedImage without anti-aliasing.
That BufferedImage is then used as a texture for openGL. Using openGL would theoretically allow me to also draw text in 3d.
For the markdown stuff I'm using a simple parser that produces "markers" that are used for rendering.
The bold text is simply drawing the texture 4 times with some offsets.
Italic text is done by slightly shifting the top vertices of each glyph.
@@quantumdeveloper2733 Incredible, so simple and so powerful =D, Thanks!
@@ricardoalcantara5846 I just did my font and UI rendering yesterday and it's much simpler, all you need to do is make a new pipeline for the ui, use orthographic projection for it, don't use the view matrix, turn off depth testing and backface culling for good measure, and then make the quad meshes for each letter sized accordingly to the pixel dimensions of the texture being used, that way, one pixel of the texture will equal one pixel on your screen, and from there it can be transformed and scaled or moved however just like any other mesh, the only difference is its position is now effectively 2D and correlates with the pixels on your screen, vec2(0,0) being the bottom left corner.
note that these are _not_ reasons that rewriting is bad (rewriting in itself is _never_ bad - the main issue is the time it takes to rewrite tbh)
the issue is making decisions that made rewriting harder
I think the main problem is the reason for the rewrite.
If like in my case the reason is "A lot of the code isn't designed to work with xyz" or "the codebase is ugly", then a rewrite from scratch is a bad idea.
A partial rewrite or refactor is always the better choice because it allows reusing the code that works fine.
@@quantumdeveloper2733 i beg to differ...
tl;dr generally "A lot of the code isn't designed to work with xyz" or "the codebase is ugly" are _excellent_ reasons to rewrite from scratch. especially if you consider the project as early in development. it's a lot better than rewriting a much more massive project because it absolutely needs one, and failing even harder (and just giving up on rewriting ever again, so you're just left with something subpar and there's nothing you can do about it)
tl;dr2 from failing at rewriting you gain experience (mistakes are the best way to gain experience!), and that will almost certainly make the code you write in the future better, even if it doesn't seem like it
"a lot of the code isn't designed to work with xyz" - it depends how you can make it work imo. e.g. sometimes you'll need to do a really hacky workaround, and... enough hacky workarounds and it'll quickly become unmaintainable
"the codebase is ugly" - generally for me that means you have to essentially fully rewrite it anyway. so if the structure could be improved too might as well do that.
that said, as i implied (?) in the original comment - it doesn't necessarily make a rewrite automatically smooth sailing. basically, doing things _differently_ doesn't mean doing things _right_. of course it's a good learning experience
slightly offtopic, re: the thing with till++... seems mostly like team communication issues honestly. idk if it's too late or what but could try trello (= github project boards) and/or hackmd (~= a roadmap doc/other documents on the repo) and/or whatever to get everyone on the same page.
this is especially important when making _huge_ changes since, well, _you_ will know the changes and therefore still be used to the codebase. but everyone else will have to read through the new code and become familiar with it. but also (as with the issue you had) sometimes they may just catch some issues (or non-issues?) you may not have caught
@@5omebody I can mostly agree with that. (You are especially right about the communication)
But from my experience when saying "A lot of the code isn't designed to work with xyz", most of the code is actually fine.
In my example modules like world generation, world saving, blocks, tools, GUI, rendering were mostly uneffected by multiplayer and only a few lines of these refer to stuff that is inaccessible in multiplayer.
So there is really no reason to rewrite these parts.
And about "the codebase is ugly": I too thought that this is a good reason to rewrite a project, and for small projects or early in development it definitely is, until I read this article: www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/
@@quantumdeveloper2733 re: "most of the code is actually fine." - well this is going to sound a bit bad but... then that just means the statement "A lot of the code isn't designed to work with xyz" is just false, right? so the issue is _not_ that "code doesn't work with xyz", so if it's not a reason at all then it couldn't possibly be a _good_ reason
tl;dr re: "small projects or early in development" - i'm pretty sure this counts as "small" (= under 100k lines) _and_ "early in development" (= few features).
re: the article. firstly, that was written in 2000. practices have changed a lot since then (esp. testing practices). tools (e.g. programming languages) have changed a lot since then.
tl;dr2 the article is _exclusively_ about commercial software - you can read through it again and try to note down where it mentions commercial stuff. so without time pressures, a lot of those issues already become non-issues
secondly that mostly applies for huge pieces of software that has already been released, has a huge userbase, must maintain 100% backwards compatibility etc.
these points will be based on points from the article:
thirdly... re: "you probably don’t even have the same programming team that worked on version one" - was there even that much development before you joined? not to mention, assuming your foremost priority is _not_ sales, there is _nothing_ wrong with making mistakes - in fact, what you learn from the mistakes will be _the most valuable takeaway_ from this project.
fourthly, see the conclusion of the article: "The old mantra build one to throw away is dangerous when applied to large scale commercial applications."
note in particular *_large scale commercial applications_* - if it's neither large scale (for now) nor commercial (for now) then the article just completely doesn't apply in the first place.
tl;dr "wasting" time sucks. but wasting more time sucks even more. and if you're not even wasting time then what's the issue tbh
Is it just me or this guy's voice is beautiful?
awesome work man
a fellow linux mint user?
gl looks promising
Hi, where did you learn OpenGL? I really want to learn it but im finding little resources. Thanks :)
Hi there ;D
Actually I learnt the basics through Cubyz.
When I joined it already had some graphics and over time I learned to work with what was there. And later I had enough knowledge of openGL, to work with the API directly.
But to answer your actual question: learnopengl.com is a pretty good website for learning. I still use it for more advanced concepts.
M should have 1 more pixel at the top...
true
should've used rust! kek
Well, I'm using Zig now. In my opinion Rust is just too annoying about lifetimes and memory safety (and compile times are terrible from what I heard).
@@quantumdeveloper2733 personally don't have any issues with compile times, and i think the added safety is well worth it, bit zig is a good choice too
Could. Not do for Minecraft, written java on PC and c++ on consoled. Makes difficult for parity and bugs for both and they’re what customers to swirtch to bed orck.
Yeah, that's terrible.
minecraft
Cubyz