3D games can be scaled to any resolution, because of the way vectors work.The menus are often 2D and in a fixed resolution. (resolution only changes in-game)

In 2D games, we have pixel-art, which shall not be transformed - because even if you maintain aspect ration - it looses quality, one way or the other.

So what 2D games did, back then, was to have only 1 resolution. And thats it.Even Starcraft and Diablo had only 1 resolution and no window mode.

Right now in my game its like this: Someone with a bigger resolution can see more, a small one sees less - nothing is stretched or scaled-down.

Someone from my team says that this seems unfair (well its not multiplayer) and it may change how someone plays the game depending on the resolution.While I think that this is true, I don't think it's an issue - and I don't see any quick fixes...

Enable interpolation and scale the sprites. It won't preserve the SNES style pixelized style, but it will make it look really smooth and nice IMO and it works perfectly with floating point coordinates scaled to any resolution. You'll need a transparent border around your 2D images to avoid aliasing. For a 2D game I made earlier, I decided on an 'internal' resolution and aspect ratio. When the screen size changed I calculated values to send to glOrtho() to keep the aspect ratio of the game by adding black borders, and then used the scissor test to disable drawing into these borders. However, to the internal functions of the game I had a constant resolution. Now, I'm assuming you're using OpenGL since you mentioned 3D, so here's the function I made:

The first part (the glOrtho() part) is pretty straightforward, but the scissor test part is pretty messy IMO. ._. The point of this method is that it allows you to draw to any resolution without having to scale your coordinates manually like when drawing in 3D. The position at (INTERNAL_WIDTH / 2, INTERNAL_HEIGHT / 2) = (400, 300) will always be the center of the screen, regardless of the screen's (or window's) actual aspect ratio or resolutions. Oh, and inputManager is just a class that handles input and translates screen coordinates to the internal resolution.

Scaling old-school pixel art is a bit of, well, an art. The best looking scaling algorithms use heuristics that do antialiasing on edges without interpolating colors everywhere. Google for the "Scale2x Algorithm", and check out http://xu4.sourceforge.net/screenshots.html for some examples of scaling algorithms applied to an old favorite.

I guess I still misunderstand the question. You don't want to scale the graphics (in a zoom sort of way) and you don't want to minimize the viewing size for people with larger resolutions. Are you looking for someone to agree with you and say you're right and your teammates shouldn't worry about it?

I guess I still misunderstand the question. You don't want to scale the graphics (in a zoom sort of way) and you don't want to minimize the viewing size for people with larger resolutions. Are you looking for someone to agree with you and say you're right and your teammates shouldn't worry about it?

I guess. I mean yeah its an advantage and it changes the way someone plays the game, but its not multiplayer and there are obviously minimal and maximum resolutionsThe game experience should be similar from a game design point of view - There are of course worries that level design and scripted events could clash with slightly varying resolutions

I'm not against rewarding someone with a larger resolution than intended, but I certainly wouldn't give anyone with a smaller resolution a disadvantage. If you allow scrolling so that people with smaller resolutions can look around (like in a dungeon crawler or RTS type game), then I don't think it would be necessary to change what you're doing now. What kind of game is this?

I guess, then, the questions you need to ask yourselves, Is the game play on larger resolutions far too different than what you intended? and Are the sprites going to seem unbearably small in a large resolution?

Is there any exploration involved? I could see a sort of "cheating" factor if I can see a dead end before it was intended, or if I'm falling down a pit I could see obstacles that needed avoiding sooner than intended. Being able to see more may influence whether or not I want to exchange my Banshee Boomerang for Holy Water. And that would be more frustrating for people with low resolutions.

Ever played Settlers 4? Higher resolution gave you a larger view of the map at any given time. And at Max resolution you got an additional GUI Tool (Bottom Left 'mini camera' in second pic) that allowed you to "focus" on a unit or given point in the map and everything within that focus area was visible to you from anywhere on the map at any given time.

I just have a greater width and height und render everything based on them IF I want people to see more if there want bigger resolutions (like Terraria). Since I use Slick2D I can also just combine the CanvasGameContainer and the ScalableGame Class to let the user scale the game

I just have a greater width and height und render everything based on them IF I want people to see more if there want bigger resolutions (like Terraria). Since I use Slick2D I can also just combine the CanvasGameContainer and the ScalableGame Class to let the user scale the game

Well I'm not doing it like that because I want to make sure that whatever resolution the player is using, is also a valid fullscreen resolution.Which is also weird because I think 1280x720, 720p, is the ideal resolution, and I have a 1080p 16:9 monitor - so it works; but in linux, the drivers doesnt list that resolution as a valid resolution and thus cant fullscreen to it, in Linux. Even though its the same aspect ratio as the native resolution - and it shouldnt be OS dependent what resolutions you can fullscreen too, since hardware stays the sameOh well, Linux...

I just have a greater width and height und render everything based on them IF I want people to see more if there want bigger resolutions (like Terraria). Since I use Slick2D I can also just combine the CanvasGameContainer and the ScalableGame Class to let the user scale the game

Well I'm not doing it like that because I want to make sure that whatever resolution the player is using, is also a valid fullscreen resolution.Which is also weird because I think 1280x720, 720p, is the ideal resolution, and I have a 1080p 16:9 monitor - so it works; but in linux, the drivers doesnt list that resolution as a valid resolution and thus cant fullscreen to it, in Linux. Even though its the same aspect ratio as the native resolution - and it shouldnt be OS dependent what resolutions you can fullscreen too, since hardware stays the sameOh well, Linux...

Fullscreen on the desktop resolution, draw to an FBO or a Pbuffer and stretch it to the screen with a scaling algorithm of your choice?

Well I'm not doing it like that because I want to make sure that whatever resolution the player is using, is also a valid fullscreen resolution.Which is also weird because I think 1280x720, 720p, is the ideal resolution, and I have a 1080p 16:9 monitor - so it works; but in linux, the drivers doesnt list that resolution as a valid resolution and thus cant fullscreen to it, in Linux. Even though its the same aspect ratio as the native resolution - and it shouldnt be OS dependent what resolutions you can fullscreen too, since hardware stays the sameOh well, Linux...

Ah, IF I want to make it that way I just get the list of resolutions with fullscreen option from the Display class If it's below your set native resolution you just scale (in 2D this can be done ith a simple glscale!) and if it's greater you work with this resoultion and render more tiles or whatever As for me I will start with a fixes resolution, because most gamers play the game in fullscreen anyway :0

I've been doing a 2D game with NES palette and resolution. I blit to a 256x240 canvas for all operations, and just use bilinear interpolation and fake scanlines to make it look presentable. I know a lot of people may not like the look of scanlines, but to me that's what gave those old games a distinct look. We preserve the 4x3 aspect ratio, and even the NES uneven 256x224 (NTSC) look. If you have a newer Java, and a decent graphics card, you can fake it pretty well.

Haha, I thought I'd get that. For old games though, the limitations of delivery were definitely there, and did contribute. I tried playing Castlevania - Symphony of the Night on XBOX 360, and had to quit early, not only for the overly compressed audio, but because graphically it looked like garbage, so I fired it up on my old PSX on a CRT. Some people like the noise. I like the noise; I like listening to LPs. To each their own. I was just providing options. If you want to evoke the same mood of what you would see back when people used CRTs, scanlines can help. In the US lots of hipsters like to drink PBR, not because it is good, but because they are douche bags. I'm not scoring myself any points here. I agree, for the most part, scanlines look like ass; so does playing Kid Icarus or Symphony of the Night on anything other than a CRT.

I promise, in 50 years people will be playing today's games with the stupid limitations that we have today simulated. Artificial aliasing, LoD switch popping, screen tearing, stuttering, hour long input delay, 60 second loading screens. I hate you. T____T

I'm not sure any of the low fidelity of the games from the last 15 years to today are going to become as iconic as the pixels and beep-boop-beep 8-bit music of yesteryear. Nostalgic references to the low-fi of yesteryear will sometimes skip decades: Bioshock evokes the scratchiness of an old gramaphone, Fallout3 the tinny speakers of a console wireless, but even as every episode of Supernatural plays tunes that belong on an 8-track, no one really cares to hear their so-so sound or the ch-chunk of changing the tracks.

I think the basic problem is that it's on the upward slope of the uncanny valley: by being representational, but doing a poor job at it (by today's standards, not the ones in effect back then), there's not a lot of aesthetic gain over being even more representational until one hits a peak of that curve, before hitting the downward slope (wherein you go from "stylized" to "plasticky and creepy").

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