 Show Posts
|
|
Pages: [1]
|
|
1
|
Game Development / Newbie & Debugging Questions / Re: Use LUA for ingame computers
|
on: 2013-03-26 20:23:51
|
Probably most programmers or script kiddies are going to like and/or had the idea of having a programmable game. But if you're concerned about players not wanting to program, maybe don't put in the feature at all? A programming game will be a very niche game, few will like it, but if you appeal to those they might like it a lot. Of commercial interest could be some kind of "edutainment" software that is targeted towards "yuppie parents" who want their kid to learn "IT stuff" early. Something like "Creative programming for kids is fun!". As a six year old I would have loved that =) It also totally depends on what you can control with the virtual computer. Some combat bots? Or maybe make it so that only some players will program, and others who don't want to program can just use and combine their modules ingame. But that is basically modding. Dragon Age had a very simple interesting module to "programm" the reactions of your NPCs. Very simple grammar, just a list of "if" event then do some slightly configurable action. http://media.giantbomb.com/uploads/0/3661/1734446-dragonage2_2011_03_13_20_41_05_49.jpgThe only other widespread easy to use programming language I can think of is excel. Or a simple variant of graphical programming languages where you connect inputs/output of modules. Like in the blender game engine. Or maybe in the even simpler form of most procedural texture generation toolkits. For example werkkzeug you just stack modules on top of each other to connect them. Very easy to grasp. http://pcg.wikidot.com/pcg-software:werkkzeugOr logo, but that's just an outdated iterative basic. Anyway, just thinking, because the idea sounds cool. |
|
|
|
|
3
|
Game Development / Shared Code / Re: Beware of Enum.values()!
|
on: 2013-03-14 05:45:59
|
I was a curious and made a few tests because I thought escape analysis would simply take care of this as long as you don't keep a reference to the Enum.values(). But it doesn't. It seems escape analysis only works for primitive arrays as a VarArg parameter. VarArgs are ok IF they are primitive and smaller than 64 elements, then they are simply allocated on the stack. Here is a link to a test program, with escape analysis that specific test is a 110 times faster! But it doesn't seem to work for object arrays :/ Defensive copies of objects returned or temp objects work rather well though. The lack of documentation and JIT compiler makes it really hard to test this stuff. |
|
|
|
|
5
|
Discussions / General Discussions / Re: Weirdest Practical Programming Language
|
on: 2013-03-10 02:31:01
|
For me the weirdest practical programming language is definitely http://en.wikipedia.org/wiki/Prolog. It's a powerful language, but even if you're fluent in iterative programming, it's a totally different way of expressing an solving a problem. For example, this supposedly solves the Towers of Hanoi problem: 1
2
3
4
5
6
7
8
9
10
11
12
| move(1,X,Y,_) :-
write('Move top disk from '),
write(X),
write(' to '),
write(Y),
nl.
move(N,X,Y,Z) :-
N>1,
M is N-1,
move(M,X,Z,Y),
move(1,X,Y,_),
move(M,Z,Y,X). |
|
|
|
|
|
6
|
Java Game APIs & Engines / JavaFX / Re: JOGL in JavaFX
|
on: 2012-09-03 06:48:55
|
I haven't gotten any response of the devs to my post on the oracle forum yet. - how to disable the Direct3D pipeline under Windows? Theoretically with "-Dprism.order=es2" which sets "PrismSettings.tryOrder = new String[] { "es2" };" This jira bug verifies that there exists an internal gles2 pipeline for windows: http://javafx-jira.kenai.com/browse/RT-11208Here is a very sad bug for you ;( http://javafx-jira.kenai.com/browse/RT-17404Apparently it was done to reduce memory footprint / startup time which makes sense, since they only use a handful of methods to handle vertex buffers, textures, framebuffers etc. But as long as you can bind JOGL to an existing gl context, it doesn't matter I think. The internal casting of Graphics to ES2Graphics is nice but the internal jogl wouldn't be updated very often anyway. *IF* and *WHEN* they release a gl es2 pipeline under windows. I don't know if you can use a OpenGL 3/4 context with a GLES context though. |
|
|
|
|
7
|
Java Game APIs & Engines / JavaFX / Re: JOGL in JavaFX
|
on: 2012-09-01 06:41:25
|
Hello Julien, thank you for your tips in edit 3, I'll check it out. I'm a bit embarrassed but I got a little lost with the NEWT classes for window handling. They are also in different packages. I'm always so damn impatient =) I have also made a post in the oracle forum, I just hope I'm not waking sleeping dogs but get a good response  https://forums.oracle.com/forums/thread.jspa?threadID=2434547&tstart=0Hopefully they'll make prism open source soon. I totally understand your hesitation about the evolving JavaFX code structure. I can also totally understand the JavaFX team desire to encapsulate the rendering pipeline to avoid breaking applications for updates. I still think it's very important to be able to do stuff like this. Edit.9: Dejay's suggestion is not trivial to implement with the latest version of JavaFX 2.2 because it is impossible to instantiate NGNode. I used NGRegion which has a public constructor and doesn't do much, but I'm hoping when they remove the _impl_ methods they will provide a better mechanism like a factory pattern where you can register rendering controllers for new nodes. Probably NGCanvas has a lot of stuff in it already for the deferring of the canvas draw calls. Edit.10: You can use com.sun.prism.es2.ES2Pipeline to get the (public static) GLFactory or directly GLFactory.getFactory(). If you find which class use this factory to create the GLDrawable, then you can do whatever you want
Edit.11: Oracle has probably dropped JOGL. All OpenGL calls seem to be done in native code. The GLDrawable contains the native window handle (see getNativeWindow()). Creating an external drawable and using it at the appropriate time seems to be the only way to support JOGL 2.0 in JavaFX.
What I've tried is implementing a "JOGLPipeline" that only seems to need 7 classes that make up the render pipeline. Basically an abstraction of shaders, vertex buffers and some predefined shaders to render shapes with compositing etc. The design of the prism renderer is pretty nice IMO. I've pasted my pathetic code for your entertainment: https://gist.github.com/35640761
2
3
4
5
6
7
| public class JOGLPipeline extends GraphicsPipeline
public class JOGLResourceFactory extends BaseShaderFactory
public class JOGLPresentable implements Presentable, GraphicsResource
public class JOGLContext extends BaseShaderContext
public class JOGLShader implements Shader
public class JOGLVertexBuffer extends VertexBuffer
public class JOGLGraphics extends BaseShaderGraphics |
And a class "com.sun.prism.jogl.JOGLPipeline extends org.dejay.prism.opengl.JOGLPipeline". This can be injected into PrismSettings (it's instantiated with string concatenation and getClassForName) PrismSettings.verbose = true; PrismSettings.tryOrder = new String[] { "jogl" }; Application.launch(args); I've only implemented some log traces and rendered an empty scene to find out what's happening. I'm not sure how to attach a jogl GLWindow to the view created by JavaFX glass. Atm I tried: 1
2
| window = NewtFactory.createWindow(view.getNativeView(), screen, new GLCapabilities(GLProfile.getDefault()));
glWindow = GLWindow.create(window); |
Log output: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
| Prism pipeline name = com.sun.prism.jogl.JOGLPipeline
(X) Got class = class com.sun.prism.jogl.JOGLPipeline
Initialized prism pipeline: com.sun.prism.jogl.JOGLPipeline
INFO: org.dejay.prism.opengl.JOGLPipeline init -
INFO: org.dejay.prism.opengl.JOGLPipeline getDefaultResourceFactory screens: 2
INFO: org.dejay.prism.opengl.JOGLResourceFactory createVertexBuffer
RESIZE: 3115294780147 w: 184 h: 162
INFO: org.dejay.prism.opengl.JOGLPipeline getDefaultResourceFactory screens: 2
INFO: org.dejay.prism.opengl.JOGLResourceFactory createRenderingContext
INFO: org.dejay.prism.opengl.JOGLResourceFactory createPresentable view: com.sun.glass.ui.win.WinView@42f25b18
INFO: org.dejay.prism.opengl.JOGLPresentable <init> context: org.dejay.prism.opengl.JOGLContext@13417588 view.getNativeView: 526108
INFO: org.dejay.prism.opengl.JOGLPresentable <init> glWindow: NEWT-GLWindow[
Helper: GLAnimatorControl: null, GLEventListeners num 0 [],
Drawable: null,
Context: null,
Window: jogamp.newt.driver.windows.WindowsWindow[Config null
, NEWT-Screen[Windows_nil-10, idx 0, refCount 0, 0x0, null, NEWT-Display[Windows_nil-1, refCount 0, hasEDT true, edtRunning true, null]]
, ParentWindow null
, ParentWindowHandle 0x8071c (true)
, WindowHandle 0x0
, SurfaceHandle 0x0 (lockedExt window false, surface false)
, Pos 64/64 (auto true), size 128x128
, Visible false, focus false
, Undecorated true (true)
, AlwaysOnTop false, Fullscreen false
, WrappedWindow null
, ChildWindows 0, SurfaceUpdatedListeners num 0 [], WindowListeners num 1 [com.jogamp.newt.opengl.GLWindow$1@19a8cd8a, ], MouseListeners num 0 [], KeyListeners num 0 [], surfaceLock <194e2c2f, 5b36cea3>[count 0, qsz 0, owner <NULL>], windowLock <6b385e1d, 41aaf8e9>[count 0, qsz 0, owner <NULL>]]]
INFO: org.dejay.prism.opengl.JOGLPresentable createGraphics
INFO: org.dejay.prism.opengl.JOGLPresentable getContentX
INFO: org.dejay.prism.opengl.JOGLPresentable getContentY
INFO: org.dejay.prism.opengl.JOGLPresentable getContentWidth
INFO: org.dejay.prism.opengl.JOGLPresentable getContentHeight
INFO: org.dejay.prism.opengl.JOGLContext updateRenderTarget
INFO: org.dejay.prism.opengl.JOGLGraphics <init> GLGraphics
INFO: org.dejay.prism.opengl.JOGLGraphics clear Color: Color[r=1.0, g=1.0, b=1.0, a=1.0]
INFO: org.dejay.prism.opengl.JOGLResourceFactory createStockShader Solid_Color
INFO: org.dejay.prism.opengl.JOGLShader <init>
INFO: org.dejay.prism.opengl.JOGLShader enable
INFO: org.dejay.prism.opengl.JOGLContext updateShaderTransform
INFO: org.dejay.prism.opengl.JOGLContext updateCompositeMode
INFO: org.dejay.prism.opengl.JOGLPresentable prepare null
INFO: org.dejay.prism.opengl.JOGLPresentable present
RESIZE: 3117915405788 w: 184 h: 163
RESIZE: 3117917257574 w: 185 h: 163
RESIZE: 3117922342587 w: 186 h: 163
INFO: org.dejay.prism.opengl.JOGLPresentable recreateOnResize
INFO: org.dejay.prism.opengl.JOGLPresentable recreateOnResize
INFO: org.dejay.prism.opengl.JOGLPresentable createGraphics
INFO: org.dejay.prism.opengl.JOGLPresentable getContentX
INFO: org.dejay.prism.opengl.JOGLPresentable getContentY
INFO: org.dejay.prism.opengl.JOGLPresentable getContentWidth
INFO: org.dejay.prism.opengl.JOGLPresentable getContentHeight
INFO: org.dejay.prism.opengl.JOGLGraphics <init> GLGraphics
INFO: org.dejay.prism.opengl.JOGLGraphics reset
INFO: org.dejay.prism.opengl.JOGLGraphics clear Color: Color[r=1.0, g=1.0, b=1.0, a=1.0]
INFO: org.dejay.prism.opengl.JOGLShader isValid
INFO: org.dejay.prism.opengl.JOGLPresentable prepare null
INFO: org.dejay.prism.opengl.JOGLPresentable present |
|
|
|
|
|
8
|
Java Game APIs & Engines / JavaFX / Re: JOGL in JavaFX
|
on: 2012-08-26 09:50:59
|
|
Hi, I just wanted to share my experiences on this topic:
Short version: on Mac OS X it can be done, although hacky.
At work we use JavaFX 2 on MacOSX for an editor / content management system with some fancy 3D graphic
eyecandy.
We needed to integrate an existing 3D engine (standalone app) and used IOSurface to show the result in JavaFX.
On Mac OS X it's rather simple to write a custom node an overwrite the _impl_createNGNode (or something).
Until 2.2 you even got a graphics object in the render call that can be cast into a jogl GL interface to access OpenGL directly.
You needed to take care about setting / saving some render states but it works pretty nice. After one beta update in 2.2 the
GLESPipeline changed and did not allow full access to OpenGL
functionality anymore. But you can still simple call opengl commands since the NGNode.render() function is called in the OpenGL render
context thread.
We had to use a outdated openGL java binding because unfortunatly neither JOGL nor LWJGL could be used (JOGL needs some
kind of window handle even though you just want to call some openGL commands, and LWJGL crashes because some static
initializer starts up AWT with makes JavaFX2 crash). But it still works very nice.
I suppose we will have to patch our hacky solution when the internal structure changes. Ideally they would implement a
factory pattern that creates the NGRender nodes corresponding to the ui data models.
There are also hints in the class files that an JavaFX 2 OpenGL implementation for Windows already exists, some strings starting
with WGLXXX, compared to the mac implementation starting with CGLXXX. But those files aren't released. I've fiddled
a bit with an own "class GLPipeline extends GraphicsPipeline" for windows, and think it can be done with about 10 classes,
but I'm not sure about legal implications till it's open sourced.
IMO it's very important that JavaFX 2 will allow low level access to 3D hardware. Many cool effects like complex
3D objects, raytracing, screen space ambient occlusion, shadow mapping, particles etc are only possible with
direct access to hardware.
I *really* hope that JavaFX 2 will indeed become open source. If they release the prism part it wouldn't be
much trouble to add an optional OpenGL pipeline for Windows. This would allow writing platform independent OpenGL
nodes.
Instead of the Canvas node, they should add a "OpenGL" node where you pass an "RenderNode" interface where
you can call openGL commands, with a predefined render state. A kind of "use at your own risk" node would be fine
with me =)
Another good feature for JavaFX 2 would be a "SharedSurface" node via DirectX shared surface / mac os x IOSurface,
so you can integrate framebuffers from other processes. This would help integrate any existing rendering solution.
|
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|
