Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (788)
Games in Android Showcase (234)
games submitted by our members
Games in WIP (860)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
   Home   Help   Search   Login   Register   
  Show Posts
Pages: [1]
1  Game Development / Newbie & Debugging Questions / Re: Platformer Gravity, the Camera and Graphical Flicker... on: 2012-04-20 17:32:39
Casting to int on rendering, is likely the best way to do it and shouldn't cause any errors.

This problem often pops up on the slick forum, and most of the time casting to int on render, is the first thing people will tell you to do.

Cool then... I'll do that. Thanks.

(Also just realized I forgot to mention the 2nd part of the image was just a Photoshop'd approximation since it was impossible to print screen it fast enough to capture the error, oh well, doesn't matter now persecutioncomplex)
2  Game Development / Newbie & Debugging Questions / Platformer Gravity, the Camera and Graphical Flicker... on: 2012-04-20 14:48:58
I've encountered a small but annoying graphical glitch in my platformer's engine.

I'm using Slick.

What happens is:
While the player is jumping and falling back down, moving the camera with it, the game's map tiles sometimes display a slight flicker about 1 pixel high on their bottom side.
Currently, the player is a green rectangle which happens to be the same colour as this flicker, and experimenting with changing the colour of the player has confirmed that it is definitely a small part of the player sprite "bleeding" through. I've made a simple diagram to help picture it better. It does happen on the white squares too, it's just not as noticeable as the brown ones. Also, for some reason it seems as though this problem isn't affecting some brown tiles, seemingly corner tiles but that's probably not important:

What I think is happening:
Through a bit of experimentation and thinking the problem through, I've determined the problem seems to come from the use of floating points to store position/velocity etc. which obviously must result in partial pixels. The main culprit appears to be the addition of the gravity value (multiplied by delta), which is the very small and exact value of 0.00075f when the player leaves the ground. Given the player's position is now being altered by tiny amounts, which then causes the camera to instantly snap based on the player's location, which then causes the game world's objects to be translated relative to the camera's rather exacting floating point coordinates... I imagine that's causing a problem for the tiny 8x8 map tiles, screwing up a line of 1 pixel or so.

As an experiment... I kept everything the way it was, but I rounded the player's drawing coordinates to an int, then did the same thing to the camera coordinates when being used to translate the game world w.r.t. the camera. That seemed to completely get rid of the problem.

My question:
Now, I'm just wondering... I suppose I have to use floats for object coordinates if I want to use gravity like I am while using a framerate independent of logic updates and the idea of using floats instead of ints seems like a useful one, so what should I do to prevent this flickering?
Should I simply keep logical coordinates as floats the way they are, and then cast them to int when it comes to rendering? Is that good practice, or a bit sloppy and error-prone? Or is there something else that would be better?
3  Game Development / Newbie & Debugging Questions / Re: Storing Game Maps as Images - What about multiple layers? on: 2012-04-18 10:08:54
Hmmmm... yes I suppose if you had to keep checking what colour a pixel was and then looking it up in a table, you'd be defeating a lot of the purpose of using a simple image. Well, given I'm trying to making a platformer, I suppose there's no real major need for a map tile to go behind an entity.
4  Game Development / Newbie & Debugging Questions / Re: Storing Game Maps as Images - What about multiple layers? on: 2012-04-17 14:03:04
Have red indicate the 'background' (You get 255 of them, and it could be used to indicate passability if you don't want to use the alpha channel), blue indicate your 'enemy', green indicate items and then your alpha channel being a binary 'passable/impassable', or if you need a pathfinder, you can treat it as a 'cost' variable. Then, in a single bitmap or PNG you've got everything you need, depending on how you want it.

Ah yes... the alpha channel came to my mind (just in passing... wasn't really sure how it might be used) but I hadn't thought about using the separate RGB values like that.

I suppose that's about the most information you could reasonably put in an image. Shouldn't be overly hard to follow then as long as you keep an organized list of what each colour means.

Thanks for that, I'll have a think about it and see what I want to do. Might keep it simple for now persecutioncomplex
5  Game Development / Newbie & Debugging Questions / Storing Game Maps as Images - What about multiple layers? on: 2012-04-17 13:41:57
So I'm looking at implementing a system of saving/loading my 2D platformer's levels using simple image files to store the tile data etc. since it seems a quick and practical way of doing so, and for something like Ludum Dare it seems popular.
I myself have made a somewhat proper level editor before for a top-down shooter in C++, but that was a lot of hassle at times and it would be nice to get something quite functional up and running before committing to spending time on something like that rather than the actual game if at all possible.

While an image file works fine for a 2D tile array, I'm wondering about how you might go about doing slightly more complicated things like placing enemies?
An enemy or any entity could be a coloured pixel in an image, but then what about the underlying tile? You'd have to either decide the underlying tile will always be empty, some specific tile, or perhaps the same as the tile to the left of it etc. Granted, for a platformer this doesn't matter as much since most of the time anything behind an enemy will simply be a blank space but for a better looking map you might want to put non-collidable background tiles, perhaps if you were in a cave or something, and then we'd run into problems.

How might you go about something like that then? Allowing a simple image to place map tiles and enemies but not have the enemies prevent you from deciding on the underlying tile? Does anyone ever tend to bother, preferring to just make a proper level editing program when a game requires that ability?
One idea I just had would be a separate image with the same map tile image on it, but with enemy positions overlaid and when the game was loading the map it could simply ignore the map tiles and place the enemies in the right positions while still allowing a human to easily place objects with a feel for where they are in the map. Might be slightly messy though, but I guess it would work.
Any better ideas for quick and easy level editing without resorting to a full editor?
I also do know about Tiled which seems quite popular, but I haven't tried to learn how to use that just yet.
6  Game Development / Newbie & Debugging Questions / Platformer: Grabbing and Climbing up Ledges? on: 2012-04-03 13:39:40
Something I've been wondering about. Might be more obvious than I realize, it just seems to be one of those apparently straightforward things that rapidly run out of control and cause confusion when you really try to work them out.

In some platformers, you can jump and grab onto platform ledges and then lift your character up onto the ledge, usually by pressing jump again. What I have in mind here mostly is Flashback, with the system I'm talking about illustrated many times in this video here:

Ok, on some level that seems simple enough, I just can't quite get my head around the exact mechanics.

How would you implement something like that?

I figure the rough outline of what's happening could be described as:
1. Player jumps toward grabbable (not a word... yet) ledge.
2. The ledge is detected by whatever means and the player position snaps to that ledge.
3. We are now in "ledge-grab mode" in some way, with all the changes in physics and controls that might involve.
4. In this mode, pressing down might make us fall, and pressing jump might make us climb
5. Climbing causes the player's position to gradually move to some point on top of the platform, roughly above where they were while grabbing.

I have a few practical problems with this though.

1. When grabbing the ledge, where should be player be positioned? Say if you had a 16x32 player sprite, you couldn't simply place the player at ( [Ledge X Position] - [Player Width]), because then it would odd graphically when the player's hands were clearly not overlapping the ledge and grabbing on. Flashback definitely seems to have the player overlap the platform in some way.
Another factor is when climbing up, the player obviously has to end up directly above solid platform, which again implies that overlapping the solid platform makes sense.
2. How should climbing up work? It needs to accommodate both a climbing animation that makes sense and the logic of standing on a platform. Perhaps position the player's centre directly on the edge of the platform, so the player graphic (if we're using standard sized sprites all of the time like 16x32 and not allowing it to go bigger sometimes) can probably look right for hanging and climbing? Then do we just make the player move upward while animating until reaching a certain point and drop onto the solid surface and continue as normal, or should the player's position actually follow some kind of more complex path while climbing? Such as upwards... then towards the ledge?

Maybe I'm overthinking this, but I've found it a bit hard to come up with a really satisfactory answer that didn't seem to leave something out.
7  Game Development / Newbie & Debugging Questions / Re: Climbing Ladders in a Platformer on: 2012-03-24 18:36:37
So for your case I would roughly do something like this:
- create 3 sorts of ladder tiles: bottom, middle, top
- a collision with bottom ladder tile, switches into climbing-ladder-state
- after climbing up and reaching a middle-ladder tile, horizontal input events are ignored
- finally a collision with ladder-top allows to leave the ladder and switch into standard running state again

I'd kind of think though that probably only 1 type of ladder tile would be necessary. Of course, it depends on how you'd want to handle ladders exactly... but it seems reasonable that you might allow jumping up to a ladder tile and pressing up to grab on. As for leaving the ladder, while I haven't got that far yet, I was thinking that if being on a ladder tile lets the player move up, then you could just let it allow the player to go up as far as until they're no longer in contact with the ladder at which point they're no longer be under the ladder's effect and just fall onto the platform or carry on as normal.
We'll see how that goes though.

Probably no need for ladder objects, in my game I have door objects because they have their own state (open or closed).

Only thing is though, should ladders really be tiles at all? If they're their own objects, then you can lay them over existing tiles and let the tile underneath show through with transparency which would probably look better than having a special top ladder tile that would break the continuity with the varying different looks of platform tile you might have.

It's a very minor and personal choice depending on how one wants to implement it though I guess.
8  Game Development / Newbie & Debugging Questions / Re: Climbing Ladders in a Platformer on: 2012-03-24 16:03:45
Yeah, seems like I should definitely add something to the Tiles, otherwise it won't be easy to use the player's position to quickly detect ladders.

Wondering now though how exactly.

If ladders aren't going to always be aligned with Tiles (and why not), then I'll need to do more than find out just if a Tile has a ladder on it.
So what I'm thinking there is... give the Tile class a Ladder reference which would be null if it has no ladder overlapping it.

Though is that wasteful? Having a ladder reference when most Tiles won't have any? And then what about the future? Maybe Tiles will have other special objects on them that might need some kind of special treatment like ladders.

So, would it be a good idea then, to instead have some sort of list of these special Entities that could be found on Tiles?
Maybe something like... a map keyed by a string, for example "LADDER", that held Entity objects (of which Ladder is a subclass in my game) so it would be easy to find if there was a Ladder on a Tile, and then get its exact position. Suppose it would be a map of Entity lists really since there might conceivably be more than 1 Ladder overlapping a Tile.

Does that sound like a good design? Trying not to overthink this and end up with some over-engineered mess that tries to account for every possible situation and every possible future development... but it's hard not to let your mind wander persecutioncomplex
9  Game Development / Newbie & Debugging Questions / Climbing Ladders in a Platformer on: 2012-03-23 20:36:52
Wondering about how to approach this...

Say I want the player to be able to climb up ladders, and use that to climb on top of otherwise solid platforms.

So far I've got:
- The ladder would be positioned on top of the solid map tile and extend down to the ground or wherever.
- The ladder could be made of ladder sections that should probably be the same size as the map tiles maybe or maybe not.
- If the player is in contact with a ladder tile, then pressing up should cause the player to move upwards, now without checking collisions between itself and the map.
- Not being in contact with a ladder tile would break the effect and reactivate map collisions and gravity etc.
- This way I imagine it would be possible to climb straight up from the bottom of the ladder, through the solid platform and then resume normal activity as soon as the top of the platform is reached and the ladder is cleared by the bottom of the player collision box.

Now, in order to accomplish that, I figure:
- Give the player a flag such as onLadder. That could be set to indicate the player should not be affected by gravity and be able to go up etc.
- Set the flag when the player is colliding with a ladder tile and the player presses up, then going out of contact with ladder tiles would unset it, as well as pressing down when there's solid ground below.

Ok, fine, but one part I'm not too sure on is how I should determine that the player is at a ladder?...

I guess the collision detection between the player and ladders should happen somewhere in the gameplay state's logic, but then when it's determined that the player is touching a ladder, how should I handle getting that across to the player object?

I suppose I could use another atLadder flag, but then we're getting a lot of flags here... I would also then possibly need something like aboveLadder for when the player is on a platform, not touching a ladder, but there's a ladder directly below on the tile underneath.
That seems kinda messy but I suppose it would work.
Should I do something where, on pressing up or down, the player object in some way queries whether or not there's a ladder below/touching?
That does seem to make sense, given that action is only ever taken if the player actually wishes to go up or down rather than it being something that happens every time they collide.
I suppose that means keeping a list of ladders somehow in the level map object that the player can query when required. Though I'm not sure how exactly that should be organized.

Do I have the right idea?

EDIT: In fact, is it worth for each map tile keeping a list of all the stationary entities (or perhaps even moving ones...) found on that tile? I suppose that would make collision detection quite quick if you just had to check what was on specific tiles, but is it worth the hassle/overhead?
10  Game Development / Newbie & Debugging Questions / Re: Jittering in Platformer when falling onto map tiles... on: 2012-03-23 19:41:27
Hmm... I later spent ages trying to figure out why something else was happening: every so often, the player would appear to move below the surface of the tile it was supposed to stop on, then flick back to its proper position.
After much printing out and comparing values and repetitive testing, I found the collision function wasn't always testing against the right tiles. Specifically, in the case above, it was testing against the tile just above where it was supposed to and I wasn't sure why for a while...
Turned out, I wasn't factor in the delta when I was determining the end point for tiles to check against. I was adding the y velocity, say, instead of yvel * delta, so the collision detection function wasn't checking far enough.
So I changed it to:
float colBoxEnd = x + ( xvel * delta ) + w;

and the other 3 cases similarly (the other directions, that one is for moving right).

Now, after some testing last night and today, it seems that all of my collision problems are gone. I haven't been able to replicate that jittering ever since factoring in the delta.
I guess it must have been checking against the wrong tiles all along  Shocked

Why position the player in case of collision at all ? If you do a look-ahead check that shouldn't be necessary.

Seemed like snapping to the closest valid position was a reasonable way of doing it.

Do you mean I should calculate the velocity required to put the player in that position instead?

I did try that before in a C++ game... I'm not sure what I went with in the end exactly. It took me ages to try a lot of different ways of getting the player to collide properly with moving enemies and in the end I just abandoned it and did things another way that was equally good or better gameplay-wise...

Why are 3. and 4. two separate steps ?

I did change that a bit... I put the gravity before the y collision checking because I realized that the new extra gravity of a frame wasn't being taken into account for collisions since it was being added after the collision checking Lips Sealed

Well, you just answered your question as to why it's happening.

If you're checking collision at the goal you'll find, in step 2, that you'll be 'colliding' with that block and your repositioning code puts you to the right of it (Since that's the rules).

Except now I'm really quite confused as to why it seems to be working perfectly...

Hmmm... looking at the exact code now I think I might see why... the separate axis testing doesn't take into account the other axis' velocity. I think that would result in what I'm seeing... yeah, I think so.

IE- Distance from important character edge X to important block edge X, divided by the current velocity. Then distance from the character edge Y to block edge Y, divided by the current velocity. Since in both cases the distance will be less than your velocity, you will have a value between [0,1]. Compare the two. The lower one is the direction in which collision with that block will first happen. If they're the same, it's a going to be a perfect corner collision, and you should decide how that works.

Interesting... I'll try to remember how that works. I've had similar problems before.

After messing around trying all I can though... I'm pretty sure it's finally working now. Have to get used to Slick and remember to always put delta in appropriate places persecutioncomplex
11  Game Development / Newbie & Debugging Questions / Re: Jittering in Platformer when falling onto map tiles... on: 2012-03-22 17:32:33
You dont do the collision check before you actually move player with intended new positions ?

What I do every frame is:
1. Figure out the x and y velocities.
2. Test if applying the x velocity to the player would result in a collision, and position the player to the edge of that tile and zero its velocity if that would occur.
3. Test the y velocity and handle that similarly.
4. Add gravity to the y velocity.
5. Add the x and y velocities to the player's position (which will be 0 by now if colliding) after multiplying by delta.

Or, is your movement time based, thus in case of too long time deltas, you get stuck in tiles ?

The movement is a speed value assigned to the velocity, which is then multiplied by delta before being added to the player position. Of course, y velocity is a bit different but jumping works that way too.

As for delta, I just had a look by printing out the delta value whenever the player lands on a platform.

It seemed to hover around either 4 or 5 no matter what. I made a few normal landings and at least 1 jittery one, but they were all either 4 or 5 (apart from the first which was 7 but I assume that was some kind of startup lag).

So I imagine it's not to do with delta being too big or so it would seem.

What does confuse me though is why this isn't happening more often... does the JNRDev tutorial's way of doing it seem to anyone else like this would be a glaring problem with it? Seems like it would have to happen with diagonal movement, which is going to occur a lot in a platformer.

As an aside too, I'm wondering if the program should be altered to run game logic a fixed amount of times per second and have rendering work independent of that, like in this article:
Or if that's even possible with Slick...
I just saw there's a way of setting VSync and smoothing deltas... trying that now. Also you can set the maximum and minimum times between updating, so that's cool.

Still, I'm pretty sure it's the algorithm that's flawed here.
Got thinking a while ago about behaving differently depending on the direction the player came from, but that would require dealing with the x and y velocities together, so I think that might be what's needed either way... which would require some reworking. Had a horrible time trying to implement something like this before in my aforementioned top down shooter. Slowly stepping through the velocities didn't work at all for whatever reason.
12  Game Development / Newbie & Debugging Questions / Jittering in Platformer when falling onto map tiles... on: 2012-03-22 13:41:25
I'm making a platformer with Slick, so I've got a level made up of tiles that the player (currently a green rectangle) can collide into and walk on etc.

I've based my collision detection largely on the JNRDev tutorial here:

I also have gravity working, where when the player is in the air, a gravity float value is added to the player's y velocity (and multiplied by Slick's delta value, keeping track of time since the last frame and making values consistent regardless of frame rate) and when the player falls into a platform, the player stops, is repositioned in line with the platform etc.

However, I've noticed some jittering behaviour... especially when I let the player's fall speed get higher. I suspect that's probably just making it more obvious and it's happening regardless of that, but w/e. Also of note is that even with the terminal velocity set relatively high, I don't always notice any jitter, though sometimes it's very noticeable. I imagine it depends on the exact velocity values at impact and where the colliding tiles are in relation to the player etc.

I've drawn a diagram to explain it clearly:

As you can see, what happens is that the player is moving downwards and to the left (or right) at the same time. On colliding with the platform, the player often sharply snaps to the right a few pixels as well as properly landing on the platform surface.
Presumably, since colliding tiles to the left are checked when the player is moving in that direction and repositioned appropriately, and horizontal collisions are checked first... what must be happening is that a collision with the tile below is detected while moving to the left, and as a result the player is undesirably being repositioned to that tile's right side... which is what the code is meant to do. It's just of course that it looks terrible and would also potentially interfere with gameplay somewhat.
Like I said though, it doesn't always appear to happen, and I'm not sure why that is... it could just be that the positioning is very small and unnoticeable, even when it seems as though the player's side edge is colliding with the center or so of a tile... but that's probably not important.

Knowing what's wrong pretty clearly... how do I actually fix it? persecutioncomplex
Horizontal collisions need to be addressed, and depending on the layout of the map and the collision, I may want the player's horizontal movement to be altered rather than the vertical in some cases. I can't simply avoid checking the player's sides when moving up/down or going at a certain speed.
I can see roughly what I want to do... but I'm finding it hard to properly define what should be done in an exact methodical way that would work in all situations Stare

Granted, something like this doesn't need to be a pixel perfect representation of the real world. For instance, in the case of landing on that platform, ignoring the x repositioning altogether and simply raising the player up above the platform would like fine, though realistically part of that leftward movement would have been achieved by traveling through solid rock but no one would notice or care.
Even still, given the various circumstances that might crop up... do I have to alter my collision detection almost entirely and use some sort of gradual pixel-by-pixel testing of at what point the collision occurs when traveling in each axis, and reposition to the point just before colliding? Which is also complicated by my use of floats to store position, but I guess that could be got around...

Any thoughts? This must be a common problem, and I think I had a similar one with a top-down shooter I made in C++.
13  Java Game APIs & Engines / Java 2D / Re: Java Slick: Adding to subclasses of StateBasedGame and scaling up the display... on: 2012-03-18 12:53:09
Firstly, Slick doesn't use Java2D so this thread should be moved. Wink

Oh right, crap, sorry. I misinterpreted the forum description as being for 2D Java graphics programming in general. Oops Tongue

For non-static variables, a common technique is to pass your own subclass of StateBasedGame to the GameState constructor (or, better yet, a "GameContext"-type interface that only implements necessary functions) so that states can access "global" resources/settings/etc.

I see... that kinda makes sense.

If you are scaling the entire screen, you might rather utilize the Graphics.scale/pushTransform/popTransform methods so that you don't need to also scale each sprite individually to the screen resolution.

Cool... it seems to be working nicely now.

Provided I haven't done anything that might be problematic for some reason...

I can scale everything properly just by changing a single float and the map tiles (which is about all I'm rendering ATM) don't know anything about the scaling but all seem to scale and line up properly. Yay.

Right now my PlatformGame class has:
public static final int WIN_RES_WIDTH = 320;
public static final int WIN_RES_HEIGHT = 200;
public static final float WIN_RES_SCALE = 2.0f;
public static final int WIN_WIDTH = ( int ) ( WIN_RES_WIDTH * WIN_RES_SCALE );
public static final int WIN_HEIGHT = ( int ) ( WIN_RES_HEIGHT * WIN_RES_SCALE );


public static void main( String[] args ) throws SlickException
   AppGameContainer app = new AppGameContainer( new PlatformGame() );

   [b]app.setDisplayMode( WIN_WIDTH, WIN_HEIGHT, false );[/b]


Everything look fine there?

One more thing... I was able to put the application into full screen no problem, but it was always ended up being aligned to the top left of the screen, which looks a bit weird. How do you make it display in the centre of the screen? I did some searching and some looking at method etc. but I couldn't find anything.

Thanks for the help.

EDIT: Another thing is... how can I put an Image in a StateBasedGame and load it? StateBasedGame's init function is final so it seems I can't override then and that makes it seem impossible to actually load an Image that way... it's just I want to put my image with all of the game's graphics in some accessible place.
14  Java Game APIs & Engines / Java 2D / Java Slick: Adding to subclasses of StateBasedGame and scaling up the display... on: 2012-03-17 17:15:47
Just getting properly started with game development in Java with Slick, after a few small games with C++ and working with Java a bit in college. It's going fine so far but a few small things are confusing me...

1. It seems a class deriving from BasicGameState has to implement certain methods such as:
public void render( GameContainer arg0, StateBasedGame arg1, Graphics arg2 )throws SlickException

That's fine, but what if you have something like:
public class PlatformGame extends StateBasedGame
public static final int SCREEN_WIDTH = 320;

And you'd like to be able to access that variable in the game's various states?

You have to implement render etc. with StateBasedGame, so then how might I access something particular to my derived class from within the methods of a class deriving from BasicGameState?
I know I COULD cast a StateBasedGame into a PlatformGame, but that seems pretty sloppy, then I dunno.

Maybe I'm missing something obvious here. It's been a while since I coded properly at all in fact.

2. The main reason I need to ask question 1 is because I want to make a game in fairly low resolution but then scale it up so that things are actually discernible on the screen.

Right now I'm messing around with 320x200 and scaling it up by 2.

What I want to know is: what is a proper way to do that? Is there a fairly standard way of setting that up in Slick? I have it working in a basic way now but I'm afraid that maybe it may require more careful attention than is necessary.

Right now my PlatformGame class (extending from StateBasedGame) has the following fields:
public static final int WIN_RES_WIDTH = 320;
public static final int WIN_RES_HEIGHT = 200;
public static final float WIN_RES_SCALE = 2.0f;

public static final int WIN_WIDTH = ( int ) ( WIN_RES_WIDTH * WIN_RES_SCALE );
public static final int WIN_HEIGHT = ( int ) ( WIN_RES_HEIGHT * WIN_RES_SCALE );

My main then has:
AppGameContainer app = new AppGameContainer( new PlatformGame() );

app.setDisplayMode( WIN_WIDTH, WIN_HEIGHT, false );

So that sets up a window that's twice the resolution I want.

Then to actually draw something, I access the resolution scaling value and alter the coordinates appropriately such as in this code I'm using to draw map tiles:
draw( x / TILE_SIZE * TILE_SIZE * PlatformGame.WIN_RES_SCALE,
            y / TILE_SIZE * TILE_SIZE * PlatformGame.WIN_RES_SCALE,
            x / TILE_SIZE * TILE_SIZE * PlatformGame.WIN_RES_SCALE + TILE_SIZE * PlatformGame.WIN_RES_SCALE,
            y / TILE_SIZE * TILE_SIZE * PlatformGame.WIN_RES_SCALE + TILE_SIZE * PlatformGame.WIN_RES_SCALE,
            spriteSheetX * TILE_SIZE,
            spriteSheetY * TILE_SIZE, spriteSheetX * TILE_SIZE + TILE_SIZE,
            spriteSheetY * TILE_SIZE + TILE_SIZE );

The last 3 arguments are what part of the sprite sheet to draw and of course irrelevant here, but you can see the first 4 arguments are a bit of a convoluted mess.

That's going to cause serious confusion and bugginess down the line if I leave it like that.

So, how should I scale my graphics up? There must be a relatively painless way that keeps the scaling code all in one or very few places. There must be a fairly standard solution I imagine.

3. Also, I see you can draw images using the Image class' own draw() method, but also there appears to be a list of identical functions in the Graphics class called drawImage(). What's the difference between those? Are there situations where you'd need to use one way over the other? Does Image.draw() just use the methods of the AppGameContainer's Graphics object implicitly?
Pages: [1]
hadezbladez (2078 views)
2018-11-16 13:46:03

hadezbladez (796 views)
2018-11-16 13:41:33

hadezbladez (2047 views)
2018-11-16 13:35:35

hadezbladez (412 views)
2018-11-16 13:32:03

EgonOlsen (3441 views)
2018-06-10 19:43:48

EgonOlsen (3663 views)
2018-06-10 19:43:44

EgonOlsen (2270 views)
2018-06-10 19:43:20

DesertCoockie (2991 views)
2018-05-13 18:23:11

nelsongames (3059 views)
2018-04-24 18:15:36

nelsongames (3724 views)
2018-04-24 18:14:32
Deployment and Packaging
by philfrei
2019-02-17 20:25:53

Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20 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‑
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!