Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1075208 Posts in 44099 Topics- by 36081 Members - Latest Member: workhouse

December 26, 2014, 12:00:40 PM
TIGSource ForumsDeveloperTechnical (Moderators: Glaiel-Gamer, ThemsAllTook)Reference terms in your code for pixels and scaled pixels
Pages: [1]
Print
Author Topic: Reference terms in your code for pixels and scaled pixels  (Read 404 times)
happymonster
Level 10
*****



View Profile WWW
« on: April 01, 2013, 12:08:03 AM »

Ok, this might be hard to explain.

Let's say you have a game of around 320 x 200 that is scaled up x3, x4, etc.. to fit in the screenmode.

Now, you have the original pixel size area before scaling (used for logic) and then the scaled up pixel values for drawing, smooth scrolling, overlaid lighting effects.

My question is what do you refer to these two values as? Pixels, and scaled Pixels? Pixels and real Pixels?

Just curious! Smiley

Logged

Tixel - Paint with shapes instead of pixels!
http://forums.tigsource.com/index.php?topic=44760.0
BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #1 on: April 01, 2013, 01:26:25 AM »

I use Box2Ds terminology. "world coordinates" and "screen / pixel co-ordinates". World co-ordinates are never called pixels, they are meters or centimeters, even if historically they were derived from pixels. This avoids confusion.
Logged
powly
Level 3
***



View Profile WWW
« Reply #2 on: April 01, 2013, 01:39:03 AM »

I don't see any point in upscaling and then doing some smooth gradients or stuff. In general, mixing this 'retro' big pixel thing with modern post processing or such makes very little sense to me - it kind of seems very forced and annoyingly hipstery/wannabeish. If you want to do retro, please, do it with actual old machines. Or even better: just don't. The aesthetics are overused as hell. Especially in the indie scene. It's like nobody got a good idea of where to go after cave story was released. Nowadays we have the hardware to draw very beautiful things - let's use it.

But I guess I'd say 'buffer' and 'screen' pixels.
Logged
Belimoth
Level 10
*****


high-heeled cyberbully


View Profile
« Reply #3 on: April 01, 2013, 02:32:47 AM »

I use 'actual' and 'virtual' to refer to things before and after scaling.

EDIT: @Powly: look at your damn avatar, those aren't NES colors. Nobody talks about aesthetics in Technical.
« Last Edit: April 01, 2013, 02:45:09 AM by Belimoth » Logged

powly
Level 3
***



View Profile WWW
« Reply #4 on: April 01, 2013, 02:47:14 AM »

I've been ashamed of this for a while now and too lazy to change, I'll go see if I can find/make something more interesting to replace. I once liked stuff that looked like this, too Sad
Logged
ThemsAllTook
Moderator
Level 10
******


Alex Diener


View Profile WWW
« Reply #5 on: April 01, 2013, 06:54:22 AM »

The standard terminology for "pixels which might not directly correspond to onscreen pixels" is "points". Not a great name, since it can easily be confused with other things, but there you go.
Logged
BleakProspects
Level 4
****



View Profile WWW Email
« Reply #6 on: April 01, 2013, 07:45:24 AM »

You should never ever reference "pixels" unless you're doing something with graphics. Everything should be done in "units", and whatever is at the very end drawing stuff to the screen, knows how to convert "units" to "pixels" (but your code should be completely agnostic to this).
Logged

bluescrn
Level 1
*


Unemployed Coder / Full-time Indie :)


View Profile WWW
« Reply #7 on: April 01, 2013, 08:12:55 AM »

I use Box2Ds terminology. "world coordinates" and "screen / pixel co-ordinates". World co-ordinates are never called pixels, they are meters or centimeters, even if historically they were derived from pixels. This avoids confusion.

For 2D games, I prefer to use world coordinates based on the pixel scale of the source art. If I had 32x32 tiles, then one tile would also be 32 world units wide and tall.

This makes it easy to 'measure' distances from source assets.

Another fairly nice scale is one unit per tile, which can simplify any logic dealing with the tilemap.

Meters rarely make sense in a 2D game, IMHO. But if you use Box2D you may be forced into a real-units scale (Chipmunk is quite happy with a pixel-based scale though).
Logged

BorisTheBrave
Level 10
*****


View Profile WWW
« Reply #8 on: April 01, 2013, 12:24:36 PM »

I mean I call them "meters". They don't have to have any bearing on actual sizes.
Logged
happymonster
Level 10
*****



View Profile WWW
« Reply #9 on: April 01, 2013, 01:14:43 PM »

Not much consistency with all of us then?  Cheesy
Logged

Tixel - Paint with shapes instead of pixels!
http://forums.tigsource.com/index.php?topic=44760.0
Eigen
Level 10
*****


Jebus backups.


View Profile WWW
« Reply #10 on: April 01, 2013, 01:22:10 PM »

Well, I have elves and giants.







No, not really. But it's an interesting discussion, looking forward to what you agree upon (if anything). In my game I don't really reference them with any particular term. I have the base-scale-space and a scale value, a value that has nothing to do with game logic and only affects final output on screen.
Logged

Martin 2BAM
Level 10
*****


@iam2bam


View Profile WWW Email
« Reply #11 on: April 01, 2013, 01:41:11 PM »

I usually go for "world"/"screen"

Sometimes even use "physics" metrics too because for example Box2D was optimized for objects in the 0.1-10 meters range (or at least when I read the manual a couple of years ago was like this).

world - map/level data/entity placement/overlapping/"unscaled" pixels.
screen - "what you see", scaled pixels with camera offset applied
physics - tuned for physics engine, if applicable.

EDIT: I guess world and physics could be exactly the same, keeping the "world" definition but with the metrics with more constraints (meters, when using Box2D).
But I find it easier to work with everyday metrics, like pixels and degrees.
Seeing those values when I hover over a variable in the editor while debugging is very straightforward.

It's easier to spot a problem with an object at 100, 200 that aims at 70 in-game and in the map editor rather than 0.4, 0.8 at 1.2217 radians.
« Last Edit: April 01, 2013, 01:51:41 PM by nitram_cero (2bam) » Logged

Working on HeliBrawl
Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic