Hydro's Game Engine

Shared Code
#21

Let’s get one thing straight. Using gl calls in any fixed function way is not my interest. So I will not implement this shadow mapping, basil_.

I haven’t learned lighting yet, except for simple normal calculations. Shadows is above me right now and I don’t have the ability to work on my engine, as I need another fan to cool my PC and maybe more thermal paste.

When the time comes I’ll be able to. I’ve been prematurely optimizing my code in the down time. Basically I organized everything and did some mipmap stuff from the other post. I also worked on the structure of classes to make things much easier.

#22

Was your goal to advertise other engines from my engine that I built and trying to pose as a reference to people using vanilla OpenGL? Wow. Funny x)

Using a game engine and making a game with it is different from building one and making a game with it.

[quote]lacks in some features and manpower. (Vertex Animation (for morph animations and SoftBody animation from Blender) , Deferred Rendering , LWJGL3(some features implemented already) , Vulkan API , … )
[/quote]
I assure you its full manpower. It is built off LWJGL2 and will support animation. As far as vulkan and lwjgl3 goes, it lies in lwjgl2.

This is also a very old snapshot. I’ve at least typed 1k lines of code after this, excluding spaces.

#23

LWJGL 3 and Vulkan API aren’t features. LWJGL is a library that rolls a whole bunch of other libraries/APIs into one, single library (which is good, because I like to have everything I need in one place). The Vulkan API is included in LWJGL 3. Also, most people think that using Vulkan instead of OpenGL for rendering is the only way to give their games/engines a massive performance boost. In fact, most people are only interested in Vulkan because of demonstrations on the Internet showing how Vulkan is waaaaaay faster than OpenGL. Vulkan’s speed is the API’s main “selling point”.

OpenGL’s speed can rival that of Vulkan’s if it’s used the right way. The Approaching Zero Driver Overhead (AZDO) techniques can be used to greatly reduce driver overhead. OP can consider using these techniques in his engine. Instead of using the usual glDrawElements, or glDrawArrays, you can use glMultiDrawElementsIndirect, which is faster (unless I’m very much mistaken).

#24

No, it was not my goal to advertise JME to game makers. I just want to say, you created a game engine and have gained lots of knowledge and experience while developing it.
So i thought you may be glad to contribute your experience with JME’s developers and help to grow this engine.
I am a noob game developer and I apologies if my post bothered you.

#25

Don’t sweat it :stuck_out_tongue: Next time, if you want to talk about something that might be off-topic, please start another thread about whatever it is you want to talk about. Thank you :slight_smile:

#26

Your post didn’t cause any stress. It was largely questionable on what it meant. Each one of those engines are far superior to mine, but mine is plenty extendable and requests to be extended by beginners such as yourself.

#27

His point is that it’d be better for the community in general if we all just helped outwith jME instead of creating our own engines.

#28

Hey come on. Creating your own game engine for a game is not only rewarding but it’s yours and in your style. It’s good for the community to open source your stuff. Someone will come along and compile stuff like they always do.

#29

Er… no. It’s good for you and that’s pretty much it. If you want anyone to use your “engine” then you need to put as much work and time into it as the LibGDX team does, for example. And you need to innovate instead of redoing what everyone else does. Why would anyone switch from a more mature framework like LibGDX for someone else’s? Unless you innovate and provide solutions to problems (multi-platform one time compile like LibGDX), no one is going to bother.

#30

I don’t think you realize that you do innovate. And the things you create are of use to others. If we closed source everything then nobody knows what the hell is going on. I’m making a specific texture format that is minimalist uncompressed created from a 32/24 bit png. I’m creating a heightmap file format because… people use textures for height which is grossly unflexible and totally unnecessary. Loading is much faster too. Each game engine can benefit off other engines mechanics and open source is the way to go. I’m taking about making your game engine. Reinnovating people’s way is a good way to learn how things interact and do. You become better. Anyone who is checking out it game engine learns. jME is seasoned, yes, and it still can be extended. Not to mention it’s a higher level that isn’t that flexible when it comes to changing how features role out.

#31

It’s an unspoken rule on JGO to write some-what formally when arguing, try not to directly mention anyone :persecutioncomplex: ( This is more directed to the entire thread )


( I know I write informally all the time, but usually not to bash anyone unless ironically or to prove a point )

These sound like cool features. Why not put them into separate git repositories and work on them there (like java-lwjgl-texture-file and java-heightmap-file)? They have uses other than game development, why put them in a game library?

The java community should take a hint from python, C and rust scenes that there shouldn’t be a huge library with a billion uses, isolate the uses into code people can use with existing software. Trying to lock people into using an engine because of its exclusive features is a useless bargain of time.

#32

Unix philosophy: “Do One Thing And Do It Well!” :point:

#33

Understanding someone else’s code completely takes a huge amount of effort. I know it’s cynical, but the chance that someone will use or look through your (not yours specifically, just a general “your”) engine is miniscule. At best someone may sift through it to rip some specific feature from it, but even that is rare. It’s just much more effort than using a well-known, well-documented library with lots of discussion and tutorials around it already. I mean, ask yourself how many of the undocumented open-source engines you’ve used or looked through made by the people of this forum. I bet you haven’t even tried out LibGDX at all. =P I am/was like that too.

If your goal is to learn more and get a deeper understanding of engines by rolling your own engine, then by all means do so. It’s a massive learning experience, not to mention fun as hell. However, if you want other people to actually use and benefit from your work, then either contributing to an existing lib/engine (LibGDX, jME, LWJGL, JOML, anything) or building tools/utilities that build on top (or work alongside like Artemis) of other popular libraries is the way to go. That way you have a 1000x better chance to contribute something that matters.

#34

[quote]Understanding someone else’s code completely takes a huge amount of effort.
[/quote]
Never quite ran into that error with code. With Matrices and huge amounts of cute math stuff, I have ran into that error. Such as JOML’s (I read as Just Onother Markup Language lol) Intersection4 classes maths to check intersection. That I agree on.

[quote] I bet you haven’t even tried out LibGDX at all.
[/quote]
I’ve said this multiple times. This thread has a boat load of hits. If at least one person benefits that is good.

That goes along with this quote: …may sift through it to rip some specific feature from it…
This is exactly what I like. Rip the feature. Learn the feature. Implement the feature. Do something.

I learned Java by sample code. I pride myself with typing neat as possible code. This is subjective. (Its my enjoyment.)

[quote]( I know I write informally all the time, but usually not to bash anyone unless ironically or to prove a point )
[/quote]
Hippo Critical strike detected (hippo crit) :point: :persecutioncomplex: ::slight_smile: ;D ;D

[quote]Unix philosophy: “Do One Thing And Do It Well!” Pointing
[/quote]
Eww Unix :^)

[quote]These sound like cool features. Why not put them into separate git repositories and work on them there (like java-lwjgl-texture-file and java-heightmap-file)? They have uses other than game development, why put them in a game library?
[/quote]
They aren’t going in a library. They will be distributed alongside with my terrain editor. The editor revolves around the XM file format. The development of XMT is complete. Please note I changed the name from mx to xm. Originally I had the name as “Mixer” and I have that habit in my head (mix files). I wanted XM at the start. It is XM.

XMT, XMH files to be exact. XMT is texture. XHM is heightmap. It will be feature a module to convert whatever I can support to XMT as a separate binary with utilizing String[] args.

Currently XMT only supports conversion from PNG. Future, definitely BMP. I am inable to convert from XMT to PNG. I have to reverse the decode process, which isnt a big deal.

Heightmaps are a different story. I actually need the editor to distribute it. If I don’t, then how is the file going to be of any use? Sure, I could write a plugin for some other program but ivent found one. The file format’s creation or loading is no secret. So i’ll let the source code go. I won’t support git hub for the editor. No need. I will have binaries. I created cute little icons for them just for this purpose. I will feature plugin support and dynamic editor variables. This will make it so the community can take over the project without having to touch the source code (this is why eclipse still exists). So theres that.

Final thing I want is to feature a compression module which compresses and uncompresses the files like PNG files. This will allow small, small files sizes and whats good is its lossless. I will feature a uncompression method. This will be a separate module. It SHOULD be used in production in places such as installers. This allows fast file transfer. I could just use 7zip maybe. Idk. I haven’t tested anything.

[quote] there shouldn’t be a huge library with a billion uses
[/quote]
Its obvious to see that I am working that way. :slight_smile:

Another thing I wanted to note was, thank you for taking interest and or supporting this.

#35

Wouldn’t it be better to have a library for your format and a second project for the editor?
No offense, but if it’s proprietary and hard for other people to contribute to, nobody’s going to use it.

Texture != Image, unless there’s a need for generating mipmaps of heightmaps

Ah, so it’s a lossless compression format for images!
… So PNG?

A library for this format can have an encode function + decode function, it’s a hell of a lot more easier than coding a proprietary UI around it.

Worldmachine is a pretty cool editor, although it’s non-free software. Make a java port of it with JavaFX with all the features and I’ll pitch into this idea!
Actually that’s a very good idea and if you’re not going to do it I am

If you’re releasing binaries, source, and probably documentation, there is a need for git.

I don’t know about that :persecutioncomplex:

#36

It doesn’t need to be a library. But fine. I will make it a library. The library will feature the methodology and it will be imported for the system.

Its meaning is synonymous. Supporting mipmaps is a cool idea. I haven’t read up on heightmaps well enough to implement the correct method. I am going to state that I will include mipmap generation for my XMH because making smaller version will allow the user to create lower res images for things such as performance, due to fragment shader. So that is a big, big feature I will have to implement. I know what they are and the user can supply the files.
java -jar XMER.jar xmt {File, …}
That would generate an amount of mipmaps and order it I guess. The nature of how the images are stored helps out wonderfully.
Like I said, I have no correct method to do this generation.

At the moment there is no compression. So it is NOT a PNG. The methodology to use it is too dissimilar to call it a PNG.

Encode and Decode? Its compression, not encryption. Its a command line operation. This format makes it an all in one, but since I am now adding the library, the binary will request the library’s methods. It also makes it so the program can utilize multiple different things, without reused code.

When development takes to release, you could let me borrow a copy. I could just find a copy of it online, or I am sure they would let me implement a plugin if I don’t own it if they find my format good. Who knows. Takes time. Don’t even know if they support all my methods. In this case, the library will come in handy and I can just rewrite it in another language if needbe.

While git if fantastic for these things I find it quite an annoyance to use. I want to use SourceForge for the binaries, git for any source, and documentation is going to be let to the wiki there. I didn’t want to use git at all. I will have the binary have an update feature. This allows, on run, for you to update the client. Updates will not be manditory, and I plan on providing a complete change log featuring everything that has changed with current patch from last patch. This is somewhat like League of Legends patch notes.

Well you wouldn’t of replied such a copious amount of text if you weren’t intrigued. Note none of it is bashing the idea. Constructive :slight_smile:

#37

Sometimes, bashing a person’s idea can benefit him/her in several ways.

#38

Even less people would use your libraries if you don’t have them hosted on some kind of dependency hosting site. SourceForge is not the answer. Git might seem like it’s a pain in the ass until something happens and you have all your source code hosted online. It takes maybe a couple hours to learn. Or even just use the Github for Windows/OSX/Linux program that will do almost everything for you. No real excuses not to use Git at this point.

#39

As I said,

[quote]I find it quite an annoyance to use
[/quote]
I know how to use it.

#40

Encode / Decode = Encryption?? Really?? When people talk about building an encoder / decoder they talk about having the ability to read and write files of different formats.

BTW PNG is lossless compression, its basically contains a zip file inside itself. The benefits are is that the file is small even though the data could be large. What are the benefits of using your own file format?