<img src="http://octavoarte.cl/Blackbars.jpg">

O_O

yeah I'm working on automatic black bars and zooming for multi-resolution games (as a lot of people complained only on the lack of multi-resolution of my first game). Working nicely so far.

Uploaded to http://scirra.com/forum/viewtopic.php?f=16&t=7269

Please comment there if you have any ideas.

Foreground is runtime on a different aspect ratio than design-time, seen on the background. See how the objects still appear on the right position, right along the screen edge, even though the window size and aspect ratio are different (set to 16:10 at 640x480, something you'd probably get when going fullscreen in a netbook)

Mmm I'm pretty sure collision wouldn't be a problem but sorting would.

How about hexagonal-base prisms? triangular? I want to look into it but I can't yet fully grasp how this works. I want players to be able to slide along horizontal and vertical walls without getting stuck into the edges that this rectangular base iso method forces.

I could do without it anyway tho I'll just cheat a bit and use graphics that are placed diagonally across a cube. Just walking along a wall won't be as nice.

I would like, to show you what I've done so far with hooks:

That's really nice. All events?

That worked nicely even though Canvas is not being accelerated by 3D hardware. CPU consumption was noticeable but still really low (I have a decent CPU though, must try on netbook).

The thing that Rocket Engine promises is NOT Canvas. It's an HTML DOM engine, and is this DOM manipulation (traversal, insertion, deletion) which is slow, due to the standard not being geared to speed. Or ease of use. Or being just nice. Ugh.

Having seen this demo, though, and knowing IE9 will feature hardware acceleration for 2D (which means others will probably follow) makes me long for the arrival of framerate-independent 2D games for HTML5-Canvas. I wonder if there are any stretching options

Edit: Acceleration goodness in IE9

<img src="http://ieblog.members.winisp.net/images/Ted_FullGPU_1.png">

While the image editor is useful for quick prototypes, I always end up using it for stickmen or smileys or such (besides the obligatory hotspot and image point setting), as it's limited and rather buggy. I'd like to see a really really basic bug-free image editor (just color picker and brush+fill tools would do) and integration with Synfig (an animation tool) or Gimp (don't really like it but bleh) or Photoshop (guy can dream )

I like this proposal, despite of it's overwhelming redness >_<

The original animation editor shows frames as tiny thumbnails that aren't really useful at all (I can't even tell frames apart in it).

One thing I don't really like is calling functions. Mainly because that's putting logic IN the animation, which could be confusing and I could see it becoming the source of frustration(why is this being called? I can't see it in any event sheet! ARGH!). INSTEAD I would suggest something that looks almost the same but it's not: being able to fire an event, which can be used in the event sheets to do the good stuff you can doo in event sheets. This would allow complex interaction with animations right off the bat!

Woo! the drunk seagull stamp!

only if it doesn't involve having the scanlines stick to objects, as it looks horrible and should be baked into the sprite itself anyway

last time I tried a full JS game on HTML DOM+CSS it was dog slow.

That's why I never got into it.

[UPDATE: ZOOM WORKS PROPERLY NOW, ALWAYS!]

This example shows how to zoom any game layer to match a new resolution, adding black bars wherever needed.

Set the globals and watch the magicks. The object placement relative to corners will match in design and runtime, even if you change resolution or switch to fullscreen. Stretching will preserve design-time proportions. Feel free to change the design-time window size, there's an event that changes the resolution in runtime (layout1 events, has to run before the resolution event sheet) and you may toggle it or change it. Feel free to try fullscreen, etc.

Watch how the objects placement will match the runtime placement, provided you set the right values in the following global variables:

WARw, WARh: Window Aspect Ratio (width, height). If windowed, this has to match the window. If fullscreen, this should match the monitor. Popular sizes are 4:3, 16:10 and 16:9

DRw, DRh: Design Resolution (width, height). This is your target, it stays the same for the whole game no matter the current display as you design the game in that size. It assumes square pixels during design, which is the norm in desktop PCs (and Construct IDE will assume the same anyway, so it'll still match if you have something different).

yes, using a windowed game should always yield no bars, as you can see. Zooming may apply though.

used .9994

oh pfftt

I was thinking it was an action or something and feeling very confused.

It's basically the same as UberLou's with a timestamp.

I'll try and do a timestamped example.