GDR Forum Index
Podcast Podcast
Dev Dev Logs
Search Search
RSS RSS
Register Register
Log in Log in
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - This And That (unfocused randomness) Page 1, 2, 3, 4, 5, 6, 7, 8  Next
View previous topic :: View next topic  
Author Message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Thu Aug 07, 2014 8:09 am    Post subject: Development Log - This And That (unfocused randomness) Reply with quote

Ok, this will be my dev thread from now on for every little thing I make, regardless of how insignificant or useful/useless it may seem. Probably won't post often in it but I feel like I need a thread like this for everything that is not a big project in itself.

All this Zelda-Playing of the past couple of days spawned a desire to do some tiled pixeling but instead of starting right away with that, I thought a bit about tile size first.

One of my OCD pet peeves that persisted throughout my entire pixeling life about tiles and screen resolutions has always been the fact that there is never "the center pixel". Because screen dimensions and tile dimensions tend to be multiples of 2, no single pixel could ever be "the center pixel" neither on the game screen nor in any individual tile. I do not even know why this is bothering me but it does, really... somehow it just hurts knowing the center of the screen or a tile (of dimensions which are mutiples of 2) is never the center of a pixel but between pixels.

So I decided to have an odd tile size (33x33) for my next whenever/whatever project and before I knew it, a spreadsheet materialized under my fingertips, allowing me to quickly calculate a couple of fancy to know facts about any chosen resolutions and tile sizes, hence this thread... to spread this and maybe other simple stuff in the future which may or may not be of use to anyone else around here.

TileCalculations.ods

instructions: enter parameters in green fields

screenshot:


<rant>
Ok... and I haven't put down any pixels yet as I first wasted a couple of hours playing around with google docs only to come to the conclusion that it sucks for sharing files like this (on import it breaks some of the formulas so they need manual fixing in google docs and then upon downloading... .ods is not even supported and in .xlsx it breaks the formulas again resulting in an unusable download... sharing directly in google docs is useless for in read-only mode, obviously you can not enter any values and in any other mode... well, the doc is instantly modified for everyone accessing it... also, I'm amazed that upon exporting it as a webpage, it just creates a static table with the currently entered values... that's just useless. Even in LibreOffice... I wish there was a way to export simple spreadsheets like this as simple websites that allow user entry for certain fields and have the formulas running as javascript... it is the year 2014, why has not anyone thought about something essential as that yet? *mumble* *grumble*
</rant>
_________________
0xDB


Edited by 0xDB on Sat Jan 17, 2015 2:22 am; edited 2 times
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Thu Aug 07, 2014 8:41 am    Post subject: Reply with quote

I think most of us just use Google Docs instead of trying to import. My use of thumb: if anybody else will edit it, make it a google doc.
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
IMakeGames
Contributor

Joined: 13 Apr 2011
Posts: 499
Location: Austria
PostPosted: Thu Aug 07, 2014 1:31 pm    Post subject: Reply with quote

Quote:
One of my OCD pet peeves that persisted throughout my entire pixeling life about tiles and screen resolutions has always been the fact that there is never "the center pixel". Because screen dimensions and tile dimensions tend to be multiples of 2, no single pixel could ever be "the center pixel" neither on the game screen nor in any individual tile. I do not even know why this is bothering me but it does, really... somehow it just hurts knowing the center of the screen or a tile (of dimensions which are mutiples of 2) is never the center of a pixel but between pixels.

Wow, that never even occured to me!

Anyway, I really like seeing you back to do some pixeling again. May you do well! Can't wait to look at some pixels... ONE AT A TIME!! :D
_________________
My current project: Hook'd
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Fri Aug 08, 2014 2:52 am    Post subject: Reply with quote

PoV wrote:
My use of thumb: if anybody else will edit it, make it a google doc.
If I could share the google doc in a way that lets people only edit their own instance of the document without changing the original at the same time I would. There does not seem to be an obvious way to share a google doc in that way though.

IMakeGames wrote:
Wow, that never even occured to me!
The more I think about it, it is not even a real issue and having a center pixel creates other problems (which are also only problems for OC number fetishists). e.g. with a 33x33 tile, you can have a center pixel but you can not split the tile into two or four equally sized sub-tiles anymore (could do nine 11x11 tiles instead though). Also, regardless of individual tile-size, you can never have a pixel at the center of a cluster of two or four tiles... it will always be between pixels. The smallest possible cluster of 33x33 tiles with a possible pixel in the center would have to be three tiles in size. That of course is an advantage over an m2xm2 (m2 = multiple of 2) tiling where even a three tile wide cluster can not have a pixel in the center... gaaaah... brain hurts. Maybe I should leave pixels behind and go vector all the way but as long as screens are all raster based that does not fix the problem (the "problem" is only in my head anyway, I should try to find a reason why this even bothers me).
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Fri Aug 08, 2014 4:31 am    Post subject: Reply with quote

Hm... I think 27x27 would be an ideal tile-size as it subdivides nicely down to 3x3 tiles or even 1x1, keeping the possibility for a center pixel at all sizes. Could also still do multiples of 2 and shave off a pixel for graphics which "need" a center pixel but this would create a grid effect which makes objects appear darker and smaller. Could also, for centering stuff like sprites or objects that somehow "need" a visible center pixel, do some double-size resolution trickery where offsetting the special object by just one screen-pixel (while each object-pixel would be 2x2 screen-pixels in size) centers it in its position. I should quit coffee, catch some sunlight and fresh air too and maybe forget about numbers and computers forever. The pain.

_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Fri Aug 08, 2014 7:29 am    Post subject: Reply with quote

Mh...hm... I think I really will go for 27x27 optimized for todays standard 16:9 aspect ratio with an internal game resolution of 400x225 (scaling that to other real screen resolutions should be easy).

My thoughts of the past few hours in pixels:

_________________
0xDB
View user's profile Send private message Visit poster's website
Alex
Developer

Joined: 05 Sep 2005
Posts: 1159

PostPosted: Fri Aug 08, 2014 8:24 am    Post subject: Reply with quote

When I do pixel-art at small scales, odd versus even number of pixels really affects the way something looks. Some things just look better with odd numbers versus even, whereas other things look better with even versus odd.
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sat Aug 09, 2014 6:46 am    Post subject: Reply with quote

Yes, it seems to boil down to picking one or the other and then start making things work with it.

Today I created a mono-spaced 9x9 bitmap font to go along with the 27x27 tile size. I love the way the 8x8 chars on the C64 align nicely with tile-based games on it (which were usually created simply by modifying the character bit-patterns), so I wanted to have something similar here:

_________________
0xDB
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9460
Location: Not Finland
PostPosted: Sat Aug 09, 2014 3:00 pm    Post subject: Reply with quote

The only time I've used a non power-of-2 tile size was with Fenux Blade. Tiles were 20x20, which made working with a 320x200 screen easy. But I've since been seduced by the dark side, and now only work in powah-o-two :)
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Aug 10, 2014 4:27 am    Post subject: Reply with quote

In an ancient abandoned platformer project of mine (called "Violence") I used 20x20 as well for the same reason. In TankGame I used power of two except for the tank sprites which "needed" a center pixel to rotate around it without wobbleing. :P Power of two probably still makes the most sense when looking at the hardware but in terms of performance the individual tile-size should not have any impact these days as long as the texture its held on still is in power of two dimensions.

Thought about projection today. I played many classic top-down-view games and for some reason (no idea why, maybe because the graphics in other games sometimes suggested it) I thought there would be some foreshortening going on for walls even with parallel projection but unless I am doing something fundamentally wrong here there is no foreshortening needed which is kind of sweet:


This means (unless I am missing something) I could define the maps for a 2D tile based game in 3D geometry and render them in OpenGL with an orthographic projection while still keeping the tiles in a pixel-perfect 27x27 resolution for both walls and floor tiles and there would not be any odd distortion with stretched or squished pixels going on. So... the map could even be viewed from different directions without any extra effort involved and it would look like a 2D pixel art game with full artistic control over each pixel and at the same time it would really be a 3D game.
_________________
0xDB
View user's profile Send private message Visit poster's website
Sirocco
Moderator

Joined: 19 Aug 2005
Posts: 9460
Location: Not Finland
PostPosted: Sun Aug 10, 2014 7:15 am    Post subject: Reply with quote

Quote:

I thought there would be some foreshortening going on for walls even with parallel projection but unless I am doing something fundamentally wrong here there is no foreshortening needed which is kind of sweet:


That's right. Classic pseudo-top-down games align the y and z axes, so ortho mode will work just fine.
_________________
NoOP / Reyn Time -- The $ is screwing everyone these days. (0xDB)
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Fri Aug 15, 2014 5:49 am    Post subject: Reply with quote

That's really sweet. :)

Alright then, inspired by PoV, Gil and Alex' recent HTML5 hackery, I started diving into it today.

Here is a bunch of links that I am probably going to consult more excessively soon(ish) and already used them a lot to get the simple stuff below up and running:
HTML5 Docs | JavaScript Docs | CSS Docs | WebGL Reference Card 1.0 (pdf)

Test 1


Test 2


They both do almost the same, you should just see a black canvas with a border around it. In the second test I started separating and frameworkifying the code of the first example.

I love how simple it was to do this(aside from some cross-browser gl context setup crappery which thankfully was already solved by a 3rd party script). Did not need to download/compile any libraries, just opened a text-editor and started hacking away. Just like back in the C64 days where you could just flip the ON-switch and when you saw the blinking cursor under the "Ready." statement it really meant that literally as you could directly start coding.
_________________
0xDB
View user's profile Send private message Visit poster's website
Alex
Developer

Joined: 05 Sep 2005
Posts: 1159

PostPosted: Fri Aug 15, 2014 6:21 am    Post subject: Reply with quote

I haven't tried coding any webgl stuff. Part of me is thinking it would be too difficult/mathy for me. But I haven't really looked into it. How simple is that stuff?
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Fri Aug 15, 2014 7:42 am    Post subject: Reply with quote

Nice. I was going to ask you how you were drawing those boxes, 'cause I couldn't find the code. Then I realized it's a CSS border style, and your WebGL context is the blackness. ;) #duh
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Fri Aug 15, 2014 7:53 am    Post subject: Reply with quote

Alex wrote:
I haven't tried coding any webgl stuff. Part of me is thinking it would be too difficult/mathy for me. But I haven't really looked into it. How simple is that stuff?
There is a bit of high-level stuff to learn about how to define the data and about how to define how the data is supposed to be rotated,scaled and positioned. But once all of that is defined, OpenGL does all the math for us. I think it is not too hard to learn from what I remember (I briefly started getting into OpenGL a couple of years ago).

PoV wrote:
Nice. I was going to ask you how you were drawing those boxes, 'cause I couldn't find the code. Then I realized it's a CSS border style, and your WebGL context is the blackness. ;) #duh
Heh, I added the border in the beginning before I could draw anything on the canvas so I'd know the (then invisible) canvas was even there and later I just kept it in.
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sat Aug 16, 2014 7:50 am    Post subject: Reply with quote

Test 3 - implementing steady timing for logic&view updates (wip)


There seems to be a problem with the timing of logic updates. I never get the exact desired number of logic updates per second that I want. All browsers I have tested also seem to cap the rendering framerate at around 60fps when using "requestAnimationFrame".

I think this is problematic because it somehow ties the logic update speed to the framerate and then rounding issues will make exact logic timing difficult.

I should try if an "endless" loop, not relying on "requestAnimationFrame" will give better results... :/

edit: Or maybe I should use "setTimeout" or "setInterval" for the logic updates and keep them completely separated from the drawing stuff handled in "requestAnimationFrame"... I should really just try that and ignore what the HTML5 docs say about it.
_________________
0xDB
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Sat Aug 16, 2014 11:39 am    Post subject: Reply with quote

Yeah, this is something I'm not entirely clear on yet, except that we should definitely be using requestAnimationFrame. RAF is synchronized *somehow*, but what's not clear to me yet is how. I'm not 100% on this, but it's probably a Draw then Step thing, as opposed to a Step then Draw. Just be careful not to do any GPU sync/stalling operations, 'cause then you'd really be wasting time... not that we particularly know which ones stall. I definitely need to read up on this though, to find out exactly what RAF promises.

If you're concerned about your logic updates, then I suggest looking at the time (i.e. Date.now()). Track the last time you updated with the number of frames of work completed added to it, take the difference between that and now, and do that many frames of work (rounded down).
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sat Aug 16, 2014 1:05 pm    Post subject: Reply with quote

PoV wrote:
If you're concerned about your logic updates, then I suggest looking at the time (i.e. Date.now()). Track the last time you updated with the number of frames of work completed added to it, take the difference between that and now, and do that many frames of work (rounded down).
That is how I was trying to solve it in Test 3 but with that, it never quite hits the number of desired logic updates, especially for low values of it. That's because of rounding issues in the calculations which are directly influenced by the number of times RAF calls the drawing update function. In effect, this seems to make the difference between the real logic updates per second and the desired logic updates per second worse for smaller values (can still be observed in test 3).

In Test 3b, I now solved it by separating the view updates from the logic updates. I use requestAnimationFrame only for the view updates and logic updates are performed detached from that using good old setTimeout. This causes the number of times the updatelogic function can be called to be capped by the browsers timer resolution (which seems to be about 200 max in Chrome and Firefox here and about 300 in IE). This is not to be confused with the number of simulation steps that can be ran per call of the updatelogic function though, so I could easily have thousands of steps per updatelogic call if I wanted to (will keep it at something sane like 50 though which works well as it seems to lead to an integral multiple of the smallest possible timer resolution thus causing no rounding issues). I will let the browser implementation of requestAnimationFrame take care of frame skipping now instead of worrying about it myself.

Test 3b - implementing steady timing for logic&view updates (now separate from each other) (wip)

_________________
0xDB
View user's profile Send private message Visit poster's website
Gil
Developer

Joined: 14 Nov 2005
Posts: 2341
Location: Belgium
PostPosted: Sat Aug 16, 2014 2:55 pm    Post subject: Reply with quote

In theory, you want logic running in a recursive loop, graphics in an RAF loop. For recursive loops, use setTimeout(fn, 0), so it won't block the UI thread (or a higher timeout if you're doing delta time stuff).

The reason I say in theory is because RAF is more stable than setTimeout it seems, so if you can do everything with RAF, that might be better. Don't run multiple RAF loops if possible, I've seen weird performance bugs crop up when you try that.
_________________
PoV: I had to wear pants today. Fo shame!
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Aug 17, 2014 12:52 am    Post subject: Reply with quote

It is my observation that neither the setInterval/setTimeout nor the requestAnimationFrame callback functions are ever called while the tab containing the page is not selected if the browser window has multiple tabs. At least that's how it is in Chrome, haven't tested other browsers.

So... it is necessary to check the current time and catch up on logic steps(if necessary) in both scenarios whenever either callback gives us a chance to update our simulation state.

This implies it is simply not possible to have a steady/regular simulation stepping which is guaranteed to run at specific time intervals. So, we have to make up for that, trying to minimize the rounding errors that come along due to the limitation of the smallest possible timer resolution in case of setInterval/setTimeout and due to the fact of timing being tied to the display refresh rate in case of requestAnimationFrame.

It would have been nice to have steady/regular stepping guaranteed which would make some things more straightforward to code but it's no showstopper for me. As always, it's just a matter of knowing the quirks and writing additional code to deal with it as best as possible. So I will combine steady/regular simulation steps (which are somewhat guaranteed when the tab is active and visible) with time-delta based simulation steps to catch up when coming back to the tab after switching away from it for some time.

That's of course only necessary if I want the simulation to feel like it had been running continuously in the meantime, which I usually want (think about games where you wait for something to happen and you want to do something else in the meantime). It becomes a problem for applications which do a lot of heavy calculations though(e.g. raytracing) where I would normally expect these calculations to keep going in the background while I'm "away" in another tab. Obviously, "catching up" on those updates would yield no benefit over keeping the tab active in the first place.

So... maybe an endless loop would still work better, provided scripts keep being executed while the browser is away from a page.
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Aug 17, 2014 12:58 am    Post subject: Reply with quote

Maybe the solution is a new HTML5 feature called "Web Workers"... I will look into that: http://www.w3.org/TR/workers/
_________________
0xDB
View user's profile Send private message Visit poster's website
0xDB
Developer

Joined: 26 Dec 2005
Posts: 1670
Location: Your consciousness.
PostPosted: Sun Aug 17, 2014 4:37 am    Post subject: Reply with quote

Using a Worker now in Test 3c which allows steady regular logic updates independent of tab active/inactiveness and display refresh rate.

This gives the smoothest results, seemingly without any rounding problems at all. To ship around costly state transfer problems between the worker-"thread" and the main script, I simply still do the logic updates in the main script which has full access to the state whereas the worker script which runs in the background simply calls the logic update function in the main script by sending a message and it seems that message is even processed in the main page if it is invisible and on an inactive tab, allowing the simulation to keep running at all times.

On my machine, performance is best in FireFox, capping at about 1000 calls per second (1ms delay!). In IE it's sluggish, capping at around 30 calls per second and in Chrome it caps at about 230 calls per second. This is due to different implementations of timer resolution and "threading" of the scripts. I read that FireFox spawns an OS-level thread for a Worker script which explains the great performance there. In IE, I can still of course do many more than 30 logic steps per second, I just have to do more than one step per call of the update function.

In summary: I think all logic timing problems are now solved with this. :)

Now I will take a break and enjoy the rest of the weekend before I start refactoring the code for that (frameworkification and cleanup). I also need a name for my HTML5/JS framework to be... maybe I will call it RefugeeScript.

Test 3c: webgl canvas & 2d canvas overaly & step ticker in concurrent worker script

_________________
0xDB
View user's profile Send private message Visit poster's website
Alex
Developer

Joined: 05 Sep 2005
Posts: 1159

PostPosted: Sun Aug 17, 2014 7:37 am    Post subject: Reply with quote

dang.. I need to learn how to do this type of timing thing. I never really understood how this type of thing works.
I was reading about your issue and thinking web workers could maybe fix it. Cool to see that it did. I use some web workers in my pixel editor for heavy processing stuff like rotations, which could cause the script on the page to stop running without the worker. The one downside to workers is the same-origin policy which makes it unable to work offline in chrome unless you customize how chrome runs which could lead it to not being safe, or you could use soemthing like node-webkit..
Fortunately, there's another way to create webworkers so that it works offline.. this is what I used:
http://stackoverflow.com/a/19201292/3591153
View user's profile Send private message Visit poster's website
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Sun Aug 17, 2014 7:59 am    Post subject: Reply with quote

Oh wow. I've been digging in to the nuances of RAF, and a nice thing I found was that Chrome has a built-in frame debugger.

https://developer.chrome.com/devtools/docs/demos/too-much-layout

Unusually my version of chrome looks slightly different, but the frame debugger is still there. The little bar-graph icon on the right side of the icons is frame mode.

More on Timeline: https://developer.chrome.com/devtools/docs/timeline
_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
PoV
Moderator

Joined: 21 Aug 2005
Posts: 10903
Location: Canadia
PostPosted: Sun Aug 17, 2014 8:13 am    Post subject: Reply with quote

There's also this thread that I'm not entirely sure knows what it's talking about.

http://impactjs.com/forums/impact-engine/misuse-of-requestanimationframe

EDIT: Wow, can of worms. Another thread on the same thing.

http://www.chandlerprall.com/2012/06/requestanimationframe-is-not-your-logics-friend/

IMO the best way to do this would be setTimeout(func,0) inside RAF to queue the game logic separately, except there is an artificial 4 ms minimum delay introduced in to setTimeout. There's a proposed setImmediate(func) standard that actually exists in IE10, but everybody refuses to implement it.

https://code.google.com/p/chromium/issues/detail?id=146172
https://bugzilla.mozilla.org/show_bug.cgi?id=686201

Folks seem to suggest that something called postMessage is the answer, but that has its own problems.

http://dbaron.org/log/20100309-faster-timeouts
http://codeforhire.com/2013/09/21/setimmediate-and-messagechannel-broken-on-internet-explorer-10/

Haha!

* * *

Found a document/discussion on a potential new spec that handles the video game side.

https://docs.google.com/document/d/1Z9pqFkumi8UTOmKhvHQoXNCzvtAe1Pn0B2LQgFNrSBY/edit

* * *

Well after all that, I'm still not entirely convinced of a solution. A separate setInterval "thread" is prone to a different kind of desync problem. Not sure about the Web Worker thing, but at least you're utilizing another idle CPU core.

I'll probably just stick with RAF.


_________________
Mike Kasprzak
'eh whatever. I used to make AAA and Indie games | Ludum Dare | Blog | Tweetar
View user's profile Send private message
Reply to topic GDR Forum Index -> Game Developer's Refuge -> Development Log - This And That (unfocused randomness) Page 1, 2, 3, 4, 5, 6, 7, 8  Next
Game Developer's Refuge
is proudly hosted by,

HostGator

All trademarks and copyrights on this page are owned by their respective owners. All comments owned by their respective posters.
phpBB code © 2001, 2005 phpBB Group. Other message board code © Kevin Reems.