 Show Posts
|
|
Pages: [1] 2 3 ... 40
|
|
1
|
Discussions / Miscellaneous Topics / Java VS Mono ==> Java is d00med
|
on: 2009-06-09 12:33:46
|
Read this: http://tirania.org/blog/archive/2009/Jun-08.htmlWe picked Sony's PhyreEngine to demostrate how to use Mono to write the high-level code for a game using Sony's finely tuned engine. We figured this was better than showing a for loop printing the numbers 1 to 10 on the screen.
....
We were also working on completing Mono's port to the PlayStation 3's native operating system (this is different than running Mono on Linux on the PS3: that already works, and it was used for developing CellDotNet, a JIT for the PS3's SPUs). Zoltan developed the static compiler for PowerPC and I did the platform support.
Mono can now run "Hello World" on the PS3 native OS. There are still lots of ins, lots of outs and lots of whathaveyous that need to be tied up before this fully works and before we are able to run PhyreEngine# on the PS3.
Anyone wanna develop for the PS3 for free? Heh, DP  |
|
|
|
|
2
|
Discussions / Miscellaneous Topics / Re: Worst OS ever?
|
on: 2009-03-10 13:03:52
|
|
There are whispers that Android is coming to the desktop (most probably a netbook) so hopefully they will put in a proper JVM on it to speed things up......hopefully!
|
|
|
|
|
3
|
Java Game APIs & Engines / JOGL Development / Re: Scenegraph Design
|
on: 2009-01-18 16:00:31
|
I agree that it is a tedious process adding lights which is why I implemented the bounds system on top of the State. When a spatial intersects a Light's Bounds, the Light gets added to the spatial's state tree. The reason to why this is superior to the simple bounds method is that this can be done during traversal of the scene on a worker thread. I found that with a multithreaded engine design, state integrity was not always guaranteed and this was one way of doing it. But I'm glad you've got a solution that works for you DP |
|
|
|
|
4
|
Java Game APIs & Engines / JOGL Development / Re: Scenegraph Design
|
on: 2009-01-18 00:47:23
|
to add lights and fog to the spatial tree and have any children be lit
Bad idea! I tried this along time ago and unless you have some way of automatically (and very quickly) creating a octree (or similar) from spatial transforms, then neighbouring objects which would the user assume to be lit wont be... It will also make shadows very difficult. What I did to resolve this is have the Light as a Transform inside the tree, but have the LightState in each spatial whereby you can attach a Light to it. This way, your Light will move with the scenegraph and have controllers on them...etc, but will also influence the correct spatials. HTH, DP |
|
|
|
|
6
|
Java Game APIs & Engines / OpenGL Development / Re: Matrix4f and glLoadMatrix
|
on: 2008-08-18 18:42:48
|
glLoadMatrix is generally more performant then multiple JNI native calls that you oncurr with glRotate, glScale and glTransform. It also gives you the opportunity to manipulate the matrices how you see fit using methods other than what GL has integrated in it. The reason it doesn't have a Matrix class is because it is not a game engine. LWJGL provides an interface to OpenGL and stays true to that. OpenGL takes a pointer to the array of floats representing a matrix, teh equivilant to that in Java is a FloatBuffer (there are reasons for using Buffers and not arrays). I would suggest you grab vecmath from vecmath.dev.java.net and start experimenting with that. DP |
|
|
|
|
7
|
Java Game APIs & Engines / JOGL Development / Re: Vbo help
|
on: 2008-08-11 20:06:40
|
I use huge VBOs but I respect this limit (GL_MAX_ELEMENTS_VERTICES) when I draw them by using glDrawArrays
Umm...what ? GL_MAX_ELEMENT_VERTICES is not a restriction on glDrawArray, its a restriction on teh size of a VBO, which on nv is 4096. This has nothing to do with JOGL vs LWJGL...your confusing the issues... AFAIK, glDrawArray and glDrawElements give the same performance, its glDrawRangeElements that gives better performance; thats what the specs say anyways.. DP |
|
|
|
|
8
|
Java Game APIs & Engines / JOGL Development / Re: Vbo help
|
on: 2008-08-10 21:30:03
|
I do believe your tests are flawed. I had a 9200se back in the days and VBOs made a considerable difference. Not in benchmarks, but in games...real life situations. I've read that document many times, made several game engines and not one of them, in game situations did VAs out strip VBOs... And yes, I am using the ARB extension in my engines, simply because they call the same pathways as core VBOs in OpenGL1.5. I made some tests on my own game that uses huge VBOs
Im sorry, that is just stupid, there reasons for GL12.GL_MAX_ELEMENTS_VERTICES and GL12.GL_MAX_ELEMENTS_INDICES; and if your not obeying them, thats your own bloody fault. DP |
|
|
|
|
9
|
Java Game APIs & Engines / JOGL Development / Re: Vbo help
|
on: 2008-08-10 15:03:25
|
Some graphics cards treat VBOs (static and dynamic) as vertex arrays whereas they should treat only dynamic VBOs as vertex arrays and static VBOs as display lists
goueseej: Do you have any evidence to back your claims of certain cards treat VBOs as VAs ? I have not a single, recently made (From the AT9500 and up, NVidia 5900 and up) that do that... When you bind a VBO and you use it several times, you obtain the same performance than with a compiled vertex array.
Eh? Ofcourse your going to use it several times...infact, once per frame! And there are loads of frames...Regarding compiled vertex array, that extension has long been deprecated infavour of VBOs... Regarding VBO API, to me, they conform to OpenGL "standards" better than display lists, especially when you compare VBOs, PBOs to Texture uploads...create the id, upload, use ID... DP |
|
|
|
|
10
|
Game Development / Newbie & Debugging Questions / Re: 3D triangle generation from list of points
|
on: 2008-06-30 00:02:52
|
That highly depends on what your points look like. If its very uniform/grid manner, you could just create a list of "indices" that outline how the points should be stitched together into a triangle. So for a square with the points sent as (x, y): (0,0) (1, 0) (1, 1) (0, 1), the indices would be 0, 2, 1 0 3 2. the "indices" refer to the points, so index 0 refers to point (0,0) wherase 2 refers to (1,1) because you declared it 3rd...etc. I would suggest doing it in a uniform fashion like Ive outlined above and seeing how things go from there. HTH, DP |
|
|
|
|
13
|
Game Development / Newbie & Debugging Questions / Re: Listen to multiple KeyEvents at once?
|
on: 2008-06-06 20:11:44
|
Yes, there is a better way of doing it: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| private byte[] keyCodes = new byte[256];
public void keyPressed(KeyEvent e) {
keyCodes[e.getKeyCode()] = true;
}
public void keyReleased(KeyEvent e) {
keyCodes[e.getKeyCode()] = false;
}
public void update() {
if (keyCodes[KeyEvent.VK_LEFT] && keyCodes[KeyEvent.KEY_UP) {
x-=1; y-=1;
}
} |
You shouldn't do the logic on the AWT thread which the listener runs in...update should just run in a loop on the main thread. PS. Thats pseudocode i wrote in the forum, not sure if it will work or not, dont take it verbatim, but the spirit is there. DP |
|
|
|
|
15
|
Game Development / Newbie & Debugging Questions / Re: Resizing sprite (x2)
|
on: 2008-05-28 19:48:18
|
I think HQ2x is more authentic to the original. Look at the knee caps of Scale2x and HQ2x...HQ2x has a nice gradient which is what the original picture is trying to show (as opposed to the white bit of the tail which is meant to be cartoony) whereas Scale2x has a cartoony knee cap... Just my 2 pence DP |
|
|
|
|
16
|
Games Center / Showcase / Re: Legend of the Chambered
|
on: 2008-05-28 15:01:34
|
Very cool, reminds me of a game I used to play as a kid on DOS called "Nightmare 3D"...fricking amazing game that was... I did notice that the knives near the start of the map rotate around their UP axis as I rotate my view, is this a bug or the way you render things? DP |
|
|
|
|
18
|
Discussions / Miscellaneous Topics / Re: In-Memory Data Compression
|
on: 2008-05-05 19:15:27
|
DXTn compression is what you are looking for here. File formats like DDS can allow for DXTn compression... The reason for choosing DXTn compression over zip for instance is how fast you can decompress. Decompression is rather quick with DXTn, quick enough that GPUs can decode them on the fly with little to no cost at rendering speed. Just wikipedia DXTn compression on the theory behind it. Spasi has a nice tool (JSquish) that can compress files to DXTn, its in the Shared Code section i believe.. DP |
|
|
|
|
19
|
Discussions / General Discussions / Re: Deciding on minimum/target hardware levels
|
on: 2008-04-14 21:04:59
|
I can really only echo what other people have said, but regarding the OpenGL versions, 1.3 is pretty much everywhere now and you will hardly ever see anyone with less than 1.3... RE shaders, Ther are ways around using them, meta language that compile to a specific shader version is the first idea that comes to mind.. DP |
|
|
|
|
20
|
Game Development / Shared Code / Re: NanoTime for dual-core AMD systems.
|
on: 2008-04-10 00:47:22
|
Or you could just install the AMD Dual-Core Optimizer from here... The AMD Dual-Core Optimizer can help improve some PC gaming video performance by compensating for those applications that bypass the Windows API for timing by directly using the RDTSC (Read Time Stamp Counter) instruction. Applications that rely on RDTSC do not benefit from the logic in the operating system to properly account for the affect of power management mechanisms on the rate at which a processor core's Time Stamp Counter (TSC) is incremented. The AMD Dual-Core Optimizer helps to correct the resulting video performance effects or other incorrect timing effects that these applications may experience on dual-core processor systems, by periodically adjusting the core time-stamp-counters, so that they are synchronized.
It smoothed alot of the games that I have and a LWJGL app too! DP |
|
|
|
|
21
|
Game Development / Performance Tuning / Re: Thread.sleep(). A problem. Any ideas?
|
on: 2008-04-03 18:38:15
|
Regarding the AMD Dual Core nanotime bug, AMD have released a utility in August of 2007 that seams to resolve this issue: From their website: The AMD Dual-Core Optimizer can help improve some PC gaming video performance by compensating for those applications that bypass the Windows API for timing by directly using the RDTSC (Read Time Stamp Counter) instruction. Applications that rely on RDTSC do not benefit from the logic in the operating system to properly account for the affect of power management mechanisms on the rate at which a processor core's Time Stamp Counter (TSC) is incremented. The AMD Dual-Core Optimizer helps to correct the resulting video performance effects or other incorrect timing effects that these applications may experience on dual-core processor systems, by periodically adjusting the core time-stamp-counters, so that they are synchronized.
http://www.amd.com/us-en/Processors/TechnicalResources/0,,30_182_871_13118,00.htmlDP |
|
|
|
|
22
|
Java Game APIs & Engines / JOGL Development / Re: ? Saw Tooth Lighting ?
|
on: 2008-03-19 21:59:14
|
Hmmm...apologies, your right. Looks like normals are to blame. I initially thought it was something to do with the way he's set his materials up, but looking at the image he's posted, there doesnt seam to be any interpolation across the lit faces at all. I would suggest you look at the gluSphere code and copy what it is doing for normals. DP |
|
|
|
|
23
|
Java Game APIs & Engines / JOGL Development / Re: ? Saw Tooth Lighting ?
|
on: 2008-03-19 18:54:04
|
shaders are easy once you get used to the quirks. The problem is two fold really, the first one is the pixel shaders have versions that are not regressable. I.e. PS3.0 will not run on hardware that doesn't support it, meaning you can't gain from its flexibility unless you use newer hardware. Which means you are forced to create a baseline for your game/application and create multiple pixel shaders that do the same thing. The second problem is compatibility, Nvidia and ATI do things different and will have their own quirks when it comes to things, just experiement and you'll soon find them. HTH, DP |
|
|
|
|
24
|
Java Game APIs & Engines / JOGL Development / Re: ? Saw Tooth Lighting ?
|
on: 2008-03-19 18:40:07
|
The lighting is correct. However, because the lighting equation is performed per vertex then interpolated across the fragments, your precieving this as sawtooth. You have two options: 1) Increase the tesselation of the sphere. 2) Start using shaders to do your own per-pixel lighting The first option will not get rid of the artifact, but it would make it less visisble and noticable. The second option would add a significat amount of complexity to your renderer to manage shaders and uniforms correctly and in a performant manner. PS. You could also add some ambient to reduce the effect, but since your in space....there isn't any ambient lighting! So experiement with it... HTH, DP |
|
|
|
|
27
|
Games Center / 4K Game Competition - 2008 / Re: FkConflict
|
on: 2008-02-27 02:22:49
|
Love it! Have to admit it, its addictive. I showed it to my flat mate, and he got addicted too! haha. Something thats small and you could probably fit it....can you put a timer in to see how fast we've finished the game in so we can challange ourselves to finish quicker? DP |
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|
