Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (701)
Games in Android Showcase (203)
games submitted by our members
Games in WIP (774)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 2 3 [4] 5 6 ... 10
 31 
 on: 2016-12-01 02:32:06 
Started by Ecumene - Last post by Ecumene
Heya everyone! The Jam is about an hour from over at my time zone... But since I started late I'm gonna keep working on it persecutioncomplex

Here's a teaser screenshot:


To the left is the Buyables tab, you choose your next constructions there.
To the right is the alerts, it's mainly for notable events you haven't seen yet.
To the top is the adviser window, there's currently 3 advisers: legal, business, and tech (They're like the long-term tutorial. Certain messages can be silenced in the future... )
And the very top is the game-bar. It has our current company debt / money (In silicoin), company name, and timer (5 business days in the week).

The reason it took me around 3 weeks to do all that was because it's FULLY SAVE-ABLE FOLKS! ( And unfortunately easy to hack Wink )

 32 
 on: 2016-11-30 22:40:00 
Started by VoidBuffer - Last post by VoidBuffer
Just a quick update for anyone that might see this in the future.  Entities having a boolean flag on whether or not a particle effect should be used was a bad idea. You'll have graphical issues while you're waiting for your effect to complete, because only then can you reset the boolean flags on the entities.

Setting off the pooled particle effects during collision detection is the easiest way to fix my issue, which is when you'll have direct access to the entities that need particle effects.

 33 
 on: 2016-11-30 20:29:22 
Started by rokyslash - Last post by rokyslash
Yeah, but I dont know where to learn them from. There are hardly any textbooks for java multiplayer game programming. Could you just help with basic connection in my game. Just get two players to move, just two clients is enough, which would give me an idea.

 34 
 on: 2016-11-30 20:27:09 
Started by Spasi - Last post by theagentd
@Elect: I'm not trying to discourage you when it comes to jAssimp; I'm just saying that I don't think the benefits (no native code, smaller file size) outweighs the drawbacks (porting effort, maintenance as new features come out, etc).

I will be evaluating Assimp and jAssimp at some point decently soon, presumably mid-end January next year. I'm completely drowned in school work ATM and my exams are in January, but once they're done I'm gonna try to sit down and look through the documentation and get some simple stuff working. I'm fairly sure that jAssimp will be easier to use than the huge amount of interaction with native code and data that the Assimp binding will need, so I may try jAssimp first. However, do realize that if we were to adopt jAssimp for our modeling importing we'd need pretty speedy bug fixes and possibly feature requests (not likely though).

I really don't envy your project, man. 3D modeling formats are a frigging nightmare. That's why I'm worried about how long you'll be able to "last" after a couple of months of debugging why the that FBX file doesn't look like the spec says it should look, or that .blend file is completely different when a new version of Blender comes out, or why the hell you have to implement an entire programming language parser to decode a .x 3D model file. It's nothing about you personally; I just know that *I* wouldn't be able to do that for long. >___> If you seem to be able to handle it and maintain it, jAssimp would be my first choice.

 35 
 on: 2016-11-30 19:48:06 
Started by Spasi - Last post by basil_
.. and there is alot native code in jassimp

https://github.com/assimp/assimp/blob/master/port/jassimp/jassimp-native/src/jassimp.cpp

.. interesting thoughts on the native-pure sides tho'.

my 2 cents : as always it depends on the context. for instance - it would be hell to port fmod to pure java. frequent updates render maintenance stupid. on the other hand - GLM bindings would not compete with JOML.

 36 
 on: 2016-11-30 19:37:32 
Started by Spasi - Last post by elect
Do you mean Assimp or jAssimp?

Assimp itself is perfect for my use. My problem has always been that 3D model formats contain way too much useless information that I have to sift through, and all the actually useful information is in a wrong format and extremely hard to decode unless your engine/tool uses the exact same data/object structures as the 3D model format assumes.

Both, I am not doing anything else than translating what Assimp stores in cpp in java, the same data will be stored, either you consider them useful or useless

Example: I don't want to have 30 different light types (or any lights at all), crazy quaternion interpolation b├ęzier parameters, complete scene graphs with interleaved mesh "nodes" and skeleton "nodes" and texture "nodes" with 637 different matrices in each node used for different purposes with no clear explanation for what does what, support for four different animation systems, baked in textures in the model file, and even more shit. I just want a number of meshes grouped by material (1 mesh per material), simple key framed skeleton animation support and that's it.

Unless you've written a rendering system on the level of Blender or Maya or something like that, 75% of all 3D file formats are so much overkill and/or stores the data in a completely different much more complicated way that it'll make you cry yourself to sleep for months after trying (and failing) to implement them (assuming implementing the rendering system itself didn't already break you), and such a rendering system would perform so badly for a game that it'd be completely useless.

I understand your frustation, but I think then you should blame the source, rather than the format itself. Or the program used, if your designer can't custom the export that much.

My worry here is that if Assimp can support all of these completely crazy Blender, Maya and Autodesk that you can fit the entirety of the Toy Story 1-53 movies, their PC games, console ports of said games, music files, autographs and dinosaur fossil discoveries since the medieval ages in them, then Assimp must support essentially everything that every single model format has ever supported. This would essentially mean that Assimp's internal objects are by far the hardest thing ever to port to your own minimal custom format. If I need a team of 10 people and 2 years to extract 5 pieces of information from it, then it doesn't actually solve any real problems. In the end, all you need is a single solid workflow from one 3D modeling software to your game, and everything else can be funneled through that path.

Sure, but that's the challenge when you declare support for over 40 formats

In light of all this, I can not agree that jAssimp is significantly more useful than Assimp in any regard. On Android, the performance/memory usage/load time argument is 10x more important so a custom file format is even more required. This means that (j)Assimp's only real usage is in engine tools/editors running on beefy PCs used to export stuff into your own custom formats, at which point the convenience of having a pure Java implementation is far outweighed by having an automatically generated binding to a maintained project with no manual work/maintenance.

Well, you don't have to agree. Unless your game loads assets in real time, the memory usage (the only one I am sure it'll be worst) is relatively an issue.

Other than that, everything is always relative, I mean, if you need to squeeze to the last bit, you have to go c or cpp. But we do use java (you included I guess) because we repute its advantages valuable. I see the same in doing a pure java porting, but this, of course, is my point of view  Wink

EDIT: Please be aware that this is my opinion from an indie game developer perspective. If you are just making a small game for fun where you just want to be able to throw in whatever 3D model format you have lying around........ you'll still be doing 99% of the job of writing your own custom format. No matter what you use, you will be taking the data returned by (j)Assimp when it loads the file and extract the stuff you need into your own custom Model object that you can actually render. From there on, it's a very small step to add binary serialization so you can save that Model object to disk and load it directly again.

Sure, it's clear  Wink

My main object is to have support for few formats, such as stl, obj, ply, collada, md2, md5 and fbx. If some user want to have something I may port that as well.
Plus exploiting some cool post-processes to modify the original mesh, without reinventing the wheel.

 37 
 on: 2016-11-30 19:36:56 
Started by rokyslash - Last post by DarkCart
I did learn sockets, but I don't know how to actually use them and there aren't many tutorials for java game development. If its not asking too much, would it be possible for you to show me how to do it?

If you actually learned Sockets, you would know how to use them. This may be an example of the pot calling the kettle black, but do not rely on game development tutorials. They limit your java knowledge to what they are teaching you and are basically worthless if you're actually trying to learn java.

 38 
 on: 2016-11-30 19:32:03 
Started by Spasi - Last post by princec
Indeed. In fact porting from original native code is usually not a good idea anyway as it's usually C++ centric, and they do things Wrong over there  Kiss

Cas Smiley

 39 
 on: 2016-11-30 19:15:42 
Started by Spasi - Last post by theagentd
A rant worthy of a medal.

As for the Java vs native discussion - there is no such thing as time "wasted" on a Java implementation. I like things being in Java because they're easy to debug, easy to build, easy to maintain, easy to fix, easy to steal bits of code from. Native code adds a thick layer of impedance over all of that. And native code is pretty frequently fraught with the exact sorts of bugs that we switched to Java to avoid in the first place.

Cas Smiley

Thanks. =P

That's a good point, and I agree with that opinion 100%. However, in this case we're talking about replicating existing functionality in Java. I'm assuming that Assimp has its fair number of users already, so most bugs should be fixed by now. Manually converting the whole thing to Java would just add an extra layer of possible bugs on top of the original code, and cause my engine to rely on even more people that I have no real influence over. I see no real benefit in this situation from a Java version of jAssimp.

 40 
 on: 2016-11-30 19:12:03 
Started by Spasi - Last post by princec
A rant worthy of a medal.

As for the Java vs native discussion - there is no such thing as time "wasted" on a Java implementation. I like things being in Java because they're easy to debug, easy to build, easy to maintain, easy to fix, easy to steal bits of code from. Native code adds a thick layer of impedance over all of that. And native code is pretty frequently fraught with the exact sorts of bugs that we switched to Java to avoid in the first place.

Cas Smiley

Pages: 1 2 3 [4] 5 6 ... 10
 
ral0r2 (191 views)
2016-11-23 16:08:26

ClaasJG (331 views)
2016-11-10 17:36:32

CoffeeChemist (425 views)
2016-11-05 00:46:53

jay4842 (476 views)
2016-11-01 19:04:52

theagentd (487 views)
2016-10-24 17:51:53

theagentd (475 views)
2016-10-24 17:50:08

theagentd (433 views)
2016-10-24 17:43:15

CommanderKeith (431 views)
2016-10-22 15:22:05

Roquen (404 views)
2016-10-22 01:57:43

Roquen (302 views)
2016-10-17 12:09:13
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!