Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (476)
Games in Android Showcase (106)
games submitted by our members
Games in WIP (530)
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: 2014-07-23 16:23:52 
Started by BurntPizza - Last post by Screem
Made some progress on my Space Game: Gfycat link

 32 
 on: 2014-07-23 15:48:24 
Started by VIrtueeL - Last post by VIrtueeL
start to code on it? =D half a year is alot off time xD

 33 
 on: 2014-07-23 15:16:26 
Started by Thotep - Last post by matheus23
A week ago my computer stopped working (beware of thunderstorms, guys!). I was unable to even turn it on...

wow!  Shocked
In my statistics you're quite unlucky, though... Lightning struck in a friend of mine's garden (~10m away from his desk) while he had his PC turned on. He said he heard noise on his headphones, but nothing's broken for him...

So yeah, my statistics consist of two individuals, but still Cheesy

 34 
 on: 2014-07-23 15:04:13 
Started by theagentd - Last post by Cero
Freezes during loading screen, or kinda slightly after loading but before any game.

Quote
Dungeon successfully generated.
Uncaught exception in draw (main) thread:
java.lang.NullPointerException
   at engine.tile.TileRenderer.nextFrame(TileRenderer.java:302)
   at engine.WSWGraphics.renderScene(WSWGraphics.java:579)
   at engine.WSWGraphics.access$2(WSWGraphics.java:556)
   at engine.WSWGraphics$1.run(WSWGraphics.java:285)
   at net.mokyu.threading.MultithreadedExecutor.processTask(MultithreadedExecutor.java:157)
   at net.mokyu.threading.MultithreadedExecutor.run(MultithreadedExecutor.java:131)
   at engine.WSWGraphics.render(WSWGraphics.java:544)
   at game.state.StateDungeon.draw(StateDungeon.java:144)
   at game.core.Core.render(Core.java:226)
   at game.core.framework.GameFramework.step(GameFramework.java:53)
   at game.core.Core.run(Core.java:170)
   at game.core.Core.main(Core.java:143)
Exception in thread "main" java.lang.IllegalStateException: Error ending frame. Not all tasks finished.
   at engine.profile.GPUProfiler.endFrame(GPUProfiler.java:66)
   at game.state.StateDungeon.draw(StateDungeon.java:153)
   at game.core.Core.render(Core.java:226)
   at game.core.framework.GameFramework.step(GameFramework.java:53)
   at game.core.Core.run(Core.java:170)
   at game.core.Core.main(Core.java:143)

No gamepad support. Now come on guys - you really wanna play a game like this with a keyboard ? ^^'

Long time fan of these games: DMC 3, 4, Bayonetta, Prototype, Infamous, MGS Rising.   Actually did some DMC 3 and mostly 4 speedruns back then, so this excites me. Would love a well written story of course... x)

 35 
 on: 2014-07-23 14:57:09 
Started by VIrtueeL - Last post by PandaMoniumHUN
Ha, yeah. It's almost like they purposely time them to coincide with the beginning of school in August or final tests in December and April. I wonder if it has something to do with the organizers' schedules?
Don't worry, LD timings are never good for me either. Since it's always on the weekends I always have something going on like traveling, parties, visiting relatives or friends (or they're visiting us), or just something more important to do. I only got to participate once and since it was my first game jam I got over ambiguous and couldn't finish in time. Guess it sucks to be a programmer with a social life. Cheesy

 36 
 on: 2014-07-23 14:44:17 
Started by theagentd - Last post by Cero
If the game industry is amenable to rapidly iterating changes, then the CAD/CAM and medical imaging industries can get off their sodding collective idle arses and rewrite their f**king code to use the new APIs, seeing as they've got, ooh, about 10x the money compared to the game industry. Jeez, why are industry programmers so f**king lazy? Games developers practically rewrite everything from scratch with every product they make in the AAA industry.

Well yes, but, if you rewrite a medical program and it doesnt work, or doesnt work in time or contains new bugs, people are in deep shit.
And I guess its the same for like manufacturing software and all that.
The problem is that the testing of new code is just so extensive and time consuming that nobody will touch a running system.

"Science without conscience is but the ruin of the soul" (Fran├žois Rabelais).
Word.

 37 
 on: 2014-07-23 14:41:04 
Started by theagentd - Last post by princec
If the game industry is amenable to rapidly iterating changes, then the CAD/CAM and medical imaging industries can get off their sodding collective idle arses and rewrite their f**king code to use the new APIs, seeing as they've got, ooh, about 10x the money compared to the game industry. Jeez, why are industry programmers so f**king lazy? Games developers practically rewrite everything from scratch with every product they make in the AAA industry.

Cas Smiley

 38 
 on: 2014-07-23 14:31:46 
Started by BurntPizza - Last post by kevglass
I was using Twitch, http://www.twitch.tv/cokeandcode/ - not on at the moment since I'm at work.

You can try the really rough demo here if you like: https://dl.dropboxusercontent.com/u/1668516/games/roguecraft/web/index.html

Cheers,

Kev

 39 
 on: 2014-07-23 14:12:36 
Started by VIrtueeL - Last post by theagentd
A month?? NO! God DAMMIT. Of course, right when school restarts. Maybe I'll get lucky the 5th time around.
Yes that's right. It's happened 4 times now in a time when I can't do it. In a row. Grr  Roll Eyes
I've had an idea for a completely EPIC game for over half a year now. Tongue

 40 
 on: 2014-07-23 14:05:28 
Started by theagentd - Last post by theagentd
As you use some bleeding edge features, you know you're in the front line, you find bugs, it's not surprising.
The only bugs I've found in cutting edge features are the following:
 - Nvidia: When persistent buffers were first released, they had forgotten to remove the check to use the buffer while it was mapped (which was the whole point), so they were useless. (Fixed)
 - AMD: BPTC texture compression works, but can't be uploaded with glCompressedTexSubImage() as that throws an error.
 - Intel: glMultiDrawIndirect() does not work if you pass in an IntBuffer with commands instead of uploading them to the indirect draw buffer VBO.

All other bugs were in really old features:
 - Intel: Rendering to a cube map using an FBO always made the result end up on the first face (X+), regardless of which face you bound to the FBO. (Fixed)
 - Intel: Their GLSL compiler was pretty much one huge bug.
vec3 array[5];
was supported,
vec3[5] array;
threw unrelated errors all over the place. (Fixed)
 - Intel: 4x3 matrices multiplied with a vec4 resulted in a vec4 while it should result in a vec3. (Fixed)
 - AMD: Sometimes on older GPUs the result of FBO rendering becomes grayscale. I have no idea. (Fixed in newer GPUs at least)
 - AMD: Allocating texture mipmaps  in reverse order (Allocate level 10, upload level 10, allocate level 9, upload level 9, ...) hard locks the GPU. You need to allocate all mipmaps before you start uploading to them.
 - AMD: Not sure if this is a bug, but depth testing against a depth buffer with depth writing disabled and reading the same depth buffer in the shader causes undefined results on AMD cards only.

These are the ones I can remember right now anyway. This is why I like Nvidia's drivers, by the way.

Almost everyone on this forum have at at least one point in their life worked with OpenGL, either directly or indirectly. Some of us likes to go deep and use OpenGL directly through LWJGL or LibGDX
LibGDX is a middle-level API and there are other actively maintained Java bindings for the OpenGL and/or OpenGL-ES APIs including JGLFW (used in LibGDX), Android OpenGL and JOGL (JogAmp).

while others (a probable majority) prefer the increased productivity of abstractions of OpenGL like LibGDX's 2D support, JMonkeyEngine or even Java2D with OpenGL acceleration.
The build-in Java2D with OpenGL acceleration isn't very optimized and it drives Java2D performance inconsistent. Slick2D, Golden T Game Engine (GTGE) and GLG2D are more efficient.
Those examples were not meant to be exhaustive. I'm only saying that no matter how your render stuff, OpenGL matters to you since pretty much everything (except unaccelerated Java2D of course) relies on OpenGL.

OpenGL is used a lot in scientific visualization and in CAD softwares too.

Maybe you should mention that the situation is quite different in mobile environments. Intel hardware is still far behind when it deals with offscreen rendering.
I did mention that OpenGL's use in other places is what made them decide to add so much backwards compatibility.
Sadly, the existence of the compatibility mode has encouraged many important industrial customers of the graphics cards vendors (CAD programs and other 3D programs) to become dependent on the compatibility mode, so it's essentially here to stay.

I can't say much about the mobile market since I've never developed stuff for it, but I do know that OpenGLES 2 is essentially OpenGL 3 without compatibility mode. Is that what you meant?

I don't think about "market shares" and things like that but I have worked as an engineer in computer science specialized in 2D/3D visualization for more than 7 years and we are numerous to be mostly satisfied by the way OpenGL has evolved even though the slowness of some decision makers were really annoying. I prefer the evolution with a certain continuity rather than brutal questionable changes. Microsoft isn't a good example, it is very good at creating brand new APIs that only work with one or two versions of Windows and abandoning them. 2 softwares on which I worked already existed in the nineties and not all corporations can afford rewriting its rendering code every three years. OpenGL isn't only for games, it can't be designed only to please some game programmers.

I know that almost nobody agrees with me about that here but I prefer fighting against planned obsolescence. What theagentd wrote isn't apolitical. "Science without conscience is but the ruin of the soul" (Fran├žois Rabelais).
I'm not entirely sure I understood what you're saying. You're saying that I'm not taking all applications of OpenGL into account?

Spasi talked about regal. JOGL provides immediate mode and fixed pipeline emulation too in ImmModeSink and PMVMatrix which is very useful when writing applications compatible with both OpenGL and OpenGL-ES.
This is the exact reason why we don't need driver implemented immediate mode anymore. It took me just a few hours to write a decent clone of immediate mode with support for matrices, colors and texture coordinates. It even takes advantage of persistently mapped buffers to upload the vertex data if they're supported by the driver. Sure, it's probably not as fast as the driver optimized immediate mode, but frankly, if you're using immediate mode you don't care about CPU performance in the first place.



I believe that the OpenGL drivers have too many features which slows down development of them and increases the number of bugs. If the OpenGL spec only contained the bare minimum required to do everything it currently does, it'd shift the load away from the driver developers and let them focus on optimizing the drivers and more quickly adopt new functionality. The lack of older "features" can be easily implemented by for example open source libraries that expose an API that's more familiar for people coming from older versions of OpenGL, and I believe that it would not be a significant effort for them to implement the stuff that they need. The important thing here is that we'd at least get rid of the completely unused game related features, like fixed functionality multitexturing and lighting.

I think that it's clear that the game industry is pretty open to this mentality of quickly deprecating old features. See how quickly developers jumped on to Mantle for example. Maybe you're right though. Maybe what we really need isn't a new OpenGL version, but a version of OpenGL that is specifically made for games. But that's pretty much what OpenGL 5 SHOULD be. OpenGL 5 most likely won't have any new hardware features. If they completely drop backwards compatibility, it'd essentially be the same functionality as OpenGL 4 but with an API targeted for games. If the "game version" of OpenGL continued to build on the new OpenGL 5, we'd essentially get what we want from OpenGL 5. Non-game applications could still use OpenGL 4, with new features introduced as extensions over time. This wouldn't necessarily decrease the load on driver developers, but it would make the game version of OpenGL faster to develop and maintain.

Pages: 1 2 3 [4] 5 6 ... 10
 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

pw (11 views)
2014-07-24 01:59:36

Riven (10 views)
2014-07-23 21:16:32

Riven (11 views)
2014-07-23 21:07:15

Riven (12 views)
2014-07-23 20:56:16

ctomni231 (42 views)
2014-07-18 06:55:21

Zero Volt (38 views)
2014-07-17 23:47:54

danieldean (32 views)
2014-07-17 23:41:23

MustardPeter (34 views)
2014-07-16 23:30:00

Cero (50 views)
2014-07-16 00:42:17

Riven (50 views)
2014-07-14 18:02:53
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
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!