 Show Posts
|
|
Pages: [1]
|
|
1
|
Game Development / Game Mechanics / Re: Have I found a new more efficient angle-finder?
|
on: 2013-06-19 00:21:25
|
I'm not really seeing why you have to use sqrt in the first place...shouldn't angle calculation be a simple dx, dy, atan2, rotate vector?
That would be the trig route, which is fine, but then I'm not sure which is more expensive, atans or sqrts? Benchmark time! Unless it's already been proven? |
|
|
|
|
2
|
Game Development / Game Mechanics / Re: Have I found a new more efficient angle-finder?
|
on: 2013-06-19 00:14:04
|
It's usually bad form to have a check for specific edge cases in what should be a purely mathematical calculation. Also, doing so is not what you want if you are looking for performance. Here is the formal calculation: 1
2
3
4
5
| Vector2f dir = new Vector2f(x2 - x1, y2 - y1);
dir.divide(dir.magnitude()) dir.multiply(speed);
object.moveBy(dir); |
Vector2f.magnitude() is the same as Math.sqrt(dir.x * dir.x + dir.y * dir.y), so you're not going to avoid that. Ninja edit: Really, sqrts arn't going to be you're bottleneck for pretty much anything. |
|
|
|
|
4
|
Game Development / Game Mechanics / Re: Java2D rendering with BufferedImage RGB data
|
on: 2013-06-18 07:18:40
|
I think you're correct. If I'm recalling correctly, which given the hour here I may not be, I think the preferred way to do direct pixel manipulations was to use create an image that was compatible with your BufferStrategy, then grab the pixel data for that image via the "raster/alpha data" methods and manipulate it. Once the pixel level manipulation was done, you render the final product to the back buffer and flip. This keeps the strategy itself accelerated even if the "scratch image" isn't. Direct manipulation of the back buffer is definitely a no-no.  Agreed. But using the pixel array should keep the scratch image accelerated and thus help with the process, otherwise not very many gains would be had, as you still have to render to the strategy. |
|
|
|
|
5
|
Game Development / Game Mechanics / Re: Java2D rendering with BufferedImage RGB data
|
on: 2013-06-18 06:57:36
|
|
Yea, it was mostly low level pixel operations that did that, but I believe that the .getRaster().getDataBuffer() etc. stuff does successfully get around this, albeit then you have to work with color packing and manually indexing and such. So for BufferedImages, that is the best option for pixel-by-pixel access to the image, am I correct?
|
|
|
|
|
7
|
Game Development / Game Mechanics / Re: Java2D rendering with BufferedImage RGB data
|
on: 2013-06-18 06:44:59
|
As a side note, I could have sworn that I read BufferStrategy uses BufferedImages behind the scenes, but I may be wrong.
It may, but either way, it takes care of it for you and it is likely to do it well, and that is nice. Maybe I've just been lucky in the fact that I haven't tripped enough of them to blow my performance to pieces.  IIRC, I think it is mainly (or at least used to be) certain drawing operations (like transforms or compositing) or setData() etc, operations on buffered images that it didn't like. |
|
|
|
|
8
|
Game Development / Newbie & Debugging Questions / Re: My game is almost half a Gigabyte in size
|
on: 2013-06-18 06:21:27
|
I think it's for ease of processing since you don't have to unpack/decode the data on the fly. I would imagine many sound libraries would store the data in memory in an unpacked format for this reason. Just my $0.02.
That is a reason I've considered, but also, all sounds loaded into memory are in an uncompressed (raw) format. Only files streamed from the HDD avoid this (and only partly, as they must be decoded in as the stream comes in), which is what you try to do for long sounds, like background music, to avoid using hundreds of MB's. But surely the processing time required to decode many small mp3's or such is small compared to other concerns? |
|
|
|
|
9
|
Game Development / Game Mechanics / Re: Java2D rendering with BufferedImage RGB data
|
on: 2013-06-18 06:10:32
|
I DO know that when finicking around in Java2D looking for performance, it is very easy to 'trip a tripwire' and send the renderer into software rendering (making your image unmanaged), which vastly slows down everything. Another approach with Java2D is using BufferStrategy, which circumvents using BufferedImages, and, in my experience, is slightly faster. It is best used for fullscreen mode applications, however. |
|
|
|
|
10
|
Game Development / Newbie & Debugging Questions / Re: My game is almost half a Gigabyte in size
|
on: 2013-06-18 05:57:59
|
Generally you would use WAV files for short sounds (Special FX) and Mp3 or other compressed format for music and large sounds.
I've heard that, but I always wonder, why? Is it loading times? I have several theories on this, but I want to know other people's opinions on this, as I am wondering if I am doing something genuinely 'wrong.' |
|
|
|
|
11
|
Game Development / Game Mechanics / Re: Java2D rendering with BufferedImage RGB data
|
on: 2013-06-18 05:39:31
|
I'm not entirely sure what you're asking, but you can obtain the color data of a BufferedImage with this: 1
| data = ((DataBufferInt) image.getRaster().getDataBuffer()).getData(); |
That will give you an integer array (you can change it to give a byte array, etc.), with each integer corresponding to the BufferedImage's type, e.g. TYPE_INT_ARGB for ARGB packed integers. Modifying this array with also change the image, as it is a reference to the image's raster. This should be faster than Graphics.drawSomething() for some operations, but it won't be huge. If you're concerned about performance, don't be using Java2D  |
|
|
|
|
13
|
Game Development / Newbie & Debugging Questions / Re: My game is almost half a Gigabyte in size
|
on: 2013-06-17 02:09:57
|
First, if you can, use something like MP3s instead of WAVs, that will save a ridiculous amount of space.
Might need to investigate a mp3 loader or library for it, but it would be worth the investment.
EDIT: Kinda ninja'd, but yeah, WAV is totally uncompressed, and MP3 is pretty well compressed, and still sounds fine to most ppl down to about 192 Kbps or so
In regards to an mp3 loader, just use libgdx; it works quite well. Yea, well if he went LibGDX for sound then he would probably want to use it for the rest of the game (I'm still assuming he isn't already), and while it might improve performance etc, that's pretty much premature optimization and would greatly increase development time, and I find that completely changing the way you do things in the middle of a project is not the way to stay focused and get it done.  |
|
|
|
|
14
|
Game Development / Newbie & Debugging Questions / Re: My game is almost half a Gigabyte in size
|
on: 2013-06-17 01:55:52
|
|
First, if you can, use something like MP3s instead of WAVs, that will save a ridiculous amount of space.
Might need to investigate a mp3 loader or library for it, but it would be worth the investment.
EDIT: Kinda ninja'd, but yeah, WAV is totally uncompressed, and MP3 is pretty well compressed, and still sounds fine to most ppl down to about 192 Kbps or so
|
|
|
|
|
17
|
Games Center / WIP games, tools & toy projects / Re: SF Citybuilder- Buildings/Concept Art
|
on: 2013-05-27 04:49:24
|
Wow, nice art! Quick comment, I thought that if you had a day/night cycle in the game, you could use the different shading amounts at different times of day, as the 'Strong' shading struck me as looking a lot like it would at sunset, and the subtle midday. Just an idea.  Really nice though, gonna show this to my friend, he loves his Dune and such. |
|
|
|
|
18
|
Game Development / Newbie & Debugging Questions / Re: (question) Tile mapping: 1d, 2d, or 3d Array?
|
on: 2013-05-20 22:31:25
|
Which is faster for PCs/Macs?
One thing I have learned is not to worry too much about performance unless you know it's going to be an issue (e.g. bad algorithm scaling). Instead, when you start off, do what reduces the conceptual weight of the project, what makes it easier to wrap your head around, as that is more important. If you can't figure out how to do something at all, then what is the point of making it fast? From what I got from this, I think the 3D arrays are the way to go, either one big one, or 3 separate ones. example: where (x, y) is the world coordinate, and z is the layer you want to reference (0-5). or you could have it [Z][X][Y], or any other order for that matter, just be consistent in the code haha! |
|
|
|
|
19
|
Games Center / WIP games, tools & toy projects / Re: [WIP] Daedalus
|
on: 2013-04-19 03:14:21
|
The game looks awesome!
I'm getting this error:
...
I'm on Windows 7, Radeon X1950 Pro
I was also having problems regarding Basique on a laptop with crappy Gl support (game crashed before main menu showed up), but I found that if you take out the #version on the fist line of the shader file, the game works fine. Hope somebody finds this useful. |
|
|
|
|
21
|
Game Development / Newbie & Debugging Questions / Re: A good resource for anyone, first post introduction
|
on: 2013-04-09 01:19:57
|
I think it started to really 'click' for me was when I was reading a Java book from the library that had me making a simple calculator app with the AWT component subclasses etc, that's when I started to understand the Object-Oriented paradigm and the backbone concepts of programming. I recommend finding a simple task like a calculator app or similar, nothing major, and make it, following a tutorial if you need to. One of the biggest things I can say is don't try to jump off into the deep end right away, like full-fledged game development; instead start simple and try to understand what is making things happen, and then think about how to scale those concepts up to bigger things. TL;DR, start with a simple project |
|
|
|
|
22
|
Game Development / Newbie & Debugging Questions / Re: Making custom menus
|
on: 2013-04-04 15:44:11
|
Easy method is having your Canvas/JPanel/whatever implement an event Listener and test for the condition. E.g. mouse clicks for intersection with a rectangle around your text: 1
2
3
4
5
6
7
| Rectangle buttonArea;
public void mousePressed(MouseEvent e) {
if(buttonArea.contains(e.getPoint())) {
}
} |
Just use KeyListener for keys, and change which String the dot is drawn next to, and also test for 'E' being pressed, and have that do whatever action you need. |
|
|
|
|
26
|
Game Development / Shared Code / Re: Pre-multiplied Alpha for drawing particles in one pass
|
on: 2012-08-21 02:11:39
|
|
Maybe someone else has a better explanation, but as I understand, it's just another way of compositing colors, you don't need to use it, or understand why it exists, nothing, just that it is an alternative method for (in the case of OpenGL) glBlendFunc(), as well as a non-implementation specific method of compositing, so if the language/api/whatever you are using doesn't support anything like glBlendFunc you can use this. That is what I know.
|
|
|
|
|
27
|
Game Development / Shared Code / Re: Pre-multiplied Alpha for drawing particles in one pass
|
on: 2012-08-21 01:39:40
|
Could someone explain what pre-multiplied alpha is exactly? Google isn't exactly helping with its big words.
It's precisely what it sounds like: the rgb colors are multiplied with the alpha channel before anything is drawn, instead of being blended in while stuff is being drawn. So, say if you drew a transparent red [1.0f, 0.0f, 0.0f, 0.5f] (that's rgba) square, then what would end up on screen is the same as if you drew a square with the opaque color [.5f, 0.0f, 0.0f 1.0f]. Notice the 1.0f * 0.5f = 0.5f, hence 'pre-multiplication.' This is nice for large batch rendering because you can simulate blend modes just by setting the current color to draw with, instead of using glBlendFunc(). |
|
|
|
|
28
|
Games Center / Showcase / Re: Toxic Bunny HD
|
on: 2012-08-19 23:12:57
|
Damn, you got all that performance from java2d? Do you guys have any developer diaries to share?
Heh that's what I was wondering; I'd probably be over 8ms just drawing the background! (on my crappy laptop anyway) Nice job though, looks awesome! |
|
|
|
|
29
|
Java Game APIs & Engines / Java 2D / Re: Java 2D collision detection
|
on: 2012-08-19 22:32:00
|
OK, I think I got this: It looks to me like you are checking for collision with any block in the map (brute force method), but then you get out of the loop and check again if he is still colliding. Well if you don't do anything of course he is still going to be colliding! Simple (not the best, but easy to understand, which is key!) method of resolving the collsion: 1
2
3
4
5
6
7
8
9
10
11
12
13
14
| Rectangle collision = hero.intersection(collisionBlock);
if(hero.collUp) { hero.y -= collision.height;
} else if(hero.collDown) { hero.y += collision.height;
} else if(hero.collRight) { hero.x -= collision.width;
} else if(hero.collLeft) { hero.x += collision.width; } |
Put that in between the end of the collision check loop and the is-he-still-colliding check, and tell me how it goes! (Also I have more code if you need to see it to get the picture) |
|
|
|
|
|
Add your game by posting it in the WIP section,
or publish it in Showcase.
The first screenshot will be displayed as a thumbnail.
|
|
Also quite fast 
