Java-Gaming.org Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (715)
Games in Android Showcase (214)
games submitted by our members
Games in WIP (788)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: 1 ... 6 7 [8] 9 10
 71 
 on: 2017-03-25 16:08:04 
Started by EnderNinja7 - Last post by orange451
Could always give Nuklear a try.

 72 
 on: 2017-03-25 14:50:48 
Started by ral0r2 - Last post by ral0r2
Yeah I was thinking about that, but wouldn't that mean I'd have to calculate +4 paths for one entity?

 73 
 on: 2017-03-25 12:46:46 
Started by Archive - Last post by nsigma
What is a ServiceLoader? How would that work with my enums? What kind of advantages are there here?

It's the standard method built into the JDK for an abstraction to find an implementation without having any dependency on it. eg https://docs.oracle.com/javase/8/docs/api/java/util/ServiceLoader.html

What I mean is that you build an initialization step into the abstraction API that looks up implementations at runtime using ServiceLoader. This usually involves an implementation of a provider class.  That in itself isn't specific to your enums.  As part of that initialization the abstracted API (eg. code in the enum or same package) queries the provider implementation for each int value and caches it in the required enums.  The implementations do not have to initialize the enums themselves, or know anything about what mechanism you're using to cache the constant mapping.  You manage the mechanism, initialization order, etc. in one place rather than many.

The code @Archive posted where each backend has to call back into each enum, know all the possible values, do things in the right order, etc. becomes tiresome quickly the more the API expands and the more backends you have.

 74 
 on: 2017-03-25 09:29:40 
Started by EnderNinja7 - Last post by Sickan
If you're using LWJGL you'll have to roll your own GameState system for different states of the game. Typically you have a main class that handles the game loop and the rendering, that delegates the rendering of the actual current stage of the game to another class implementing the behavior of the menu, game stage; etc that the player is currently in.

I haven't found UI libraries for LWJGL that are pluggable, straightforward, and well-documented. I suggest that you roll your own, adding features that you need as you need them. It doesn't take that long to code classes for Buttons, Labels, and Windows. Finding, learning and integrating another UI library into your renderer would likely take as long if not longer.

 75 
 on: 2017-03-25 06:53:06 
Started by EnderNinja7 - Last post by EnderNinja7
(Note: I do not know in which section this thread is the most suitable. It would be a big help if the admin would move this to a more suitable section)

I have made a game (somewhat) . Now, I have to focus on the GUI side of my game. Which library is the best and the easiest to make menus, GUI items and their events?

For now I think I would have a main menu, an options menu and the game itself. Now, I can't switch windows for this. My entire OpenGL code is handled in the Renderer class. Back in those days when I worked in UE4, there were game states which made it easier to switch. Now, how do I "switch between menus" in Java and the helper libraries?

 76 
 on: 2017-03-25 06:00:06 
Started by Archive - Last post by CopyableCougar4
@theagentd: But that conversion from enum constant to backend specific integer is the same as my implementation, just using a static variable as opposed to an enum (although I would be interested in RAM usage with an enum as opposed to static class fields).

Although writing such a thin abstraction layer doesn't really seem to serve a practical purpose. It just seems to introduce more problems than it solves.

 77 
 on: 2017-03-25 02:23:57 
Started by Archive - Last post by Archive
What if the rendering is abstracted so much that symbolic constants are not used at all from the user's end

 78 
 on: 2017-03-25 00:11:04 
Started by Archive - Last post by theagentd
If you're going to have the variables inside the enums for speed, I'd use ServiceLoader to lookup the required implementation at runtime and request the underlying values from it, rather than have the implementation have to configure the enums itself - that's ... yuck!  persecutioncomplex
What is a ServiceLoader? How would that work with my enums? What kind of advantages are there here?


From my point of view, an abstraction layer shouldn't contain backend-specific data in the first place.

The abstract model should have its own, backend-independent way to differentiate between
geometry types (POINTS, LINES, TRIANGLES, QUADS, SPLINES, SPHERES, something completely different) and the backends
have to map it to their own model at some point.
I agree with this, which is why I want to go with enums for the abstraction to get compile time checking of arguments. My initial idea had the OpenGL and Vulkan constants in the enum, which was bad as it meant having backend specific data in the abstraction. However, I think putting an int field in the enum that the backend can use for mapping the enum to a constant isn't the same thing and shouldn't be bad design as it has the best performance and arguable the lowest complexity and maintenance requirements.

The mapping actually has to occur just once, for example when the geometry is read from a file.
Not in my abstraction. It's just a thin layer over OpenGL and Vulkan, so data in a buffer for example isn't tied to a specific geometry topology like triangles or points. The mapping has to be done every time you submit a draw call, and there are a lot of other cases where I'll be needing to map lots of enums to int constants for OGL and VK.


 79 
 on: 2017-03-24 19:17:05 
Started by ral0r2 - Last post by homac
How about considering all four corners of the hitbox as alternative starting points? You can add it as four additional paths from the center of the hitbox to each corner. That should work I think.

 80 
 on: 2017-03-24 18:54:29 
Started by Archive - Last post by homac
From my point of view, an abstraction layer shouldn't contain backend-specific data in the first place.

The abstract model should have its own, backend-independent way to differentiate between
geometry types (POINTS, LINES, TRIANGLES, QUADS, SPLINES, SPHERES, something completely different) and the backends
have to map it to their own model at some point.

The mapping actually has to occur just once, for example when the geometry is read from a file.

Pages: 1 ... 6 7 [8] 9 10
 
CopyableCougar4 (234 views)
2017-03-24 15:39:42

theagentd (216 views)
2017-03-24 15:32:08

Rule (275 views)
2017-03-19 12:43:22

Rule (259 views)
2017-03-19 12:42:17

Rule (263 views)
2017-03-19 12:36:21

theagentd (280 views)
2017-03-16 05:07:07

theagentd (278 views)
2017-03-15 22:37:06

theagentd (200 views)
2017-03-15 22:32:18

theagentd (194 views)
2017-03-15 22:31:11

ral0r2 (170 views)
2017-03-03 11:52:41
List of Learning Resources
by elect
2017-03-13 14:05:44

List of Learning Resources
by elect
2017-03-13 14:04:45

SF/X Libraries
by philfrei
2017-03-02 08:45:19

SF/X Libraries
by philfrei
2017-03-02 08:44:05

SF/X Libraries
by SkyAphid
2017-03-02 06:38:56

SF/X Libraries
by SkyAphid
2017-03-02 06:38:32

SF/X Libraries
by SkyAphid
2017-03-02 06:38:05

SF/X Libraries
by SkyAphid
2017-03-02 06:37:51
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!