next »

[iarwain]

thanks for the continued Mac support!

You're welcome! Although the latest update doesn't have the mac version as I had to hack Box2D again. I will recompile everything for Mac later today.

I really like where this is going, the editor feels really robust, although some docs would be great (there were a couple things I didn't find after one superficial look at it, such as: the basis of rotation (pivot point? corner?), the way to switch between tiles to put, etc).

I'll put some work in a wiki page but I don't think I'll have time to do so before the end of the compo.

However, if you look at ScrollEd.ini you'll find all the bindings. They're pretty easy to guess with that file and you can change them too, of course. By default, changing the tile model is done with the mouse wheel or by copying an already placed object with middle click. Mouse wheel + left control -> changing the current layer. The pivot point used for scale and rotation is defined in the object property in the .ini files. Most of the time I put a top left pivot for background tiles (easier for edition) and center pivot for objects that will probably be rotated at runtime.
I'm still not sure if I should override the object's pivot for editing sake and always use the top left corner, for example. Any suggestion?

Any feedback regarding the editor will be greatly appreciated before I release all this publicly on sourceforge.

what did you make this in / with? (pre-dit: I just realized that you're the one that made ORX. neat framework!)

You got your answer! Well, Scroll is a level-oriented game engine/editor. It's written in templated C++ (so as to embed directly the editor in the game exe, effortlessly) and based on orx. It currently runs on windows, mac os X and linux. I'll have an iPhone version running in a couple of months of both orx and scroll.

Any game built with scroll (like ProjectX) can embed the editor. The editor allows to test a level directly while editing, without having to restart or anything.

[György Straub]

However, if you look at ScrollEd.ini you'll find all the bindings. They're pretty easy to guess with that file and you can change them too, of course. By default, changing the tile model is done with the mouse wheel or by copying an already placed object with middle click. Mouse wheel + left control -> changing the current layer. The pivot point used for scale and rotation is defined in the object property in the .ini files. Most of the time I put a top left pivot for background tiles (easier for edition) and center pivot for objects that will probably be rotated at runtime.
I'm still not sure if I should override the object's pivot for editing sake and always use the top left corner, for example. Any suggestion?

Any feedback regarding the editor will be greatly appreciated before I release all this publicly on sourceforge.

thanks for the explanation. I gotta be the one with the craziest input devices as I'm commuting between a touchpad and a tablet.=D

as for the pivot point, I use a central pivot point in my framework. it goes together with halfsize vectors and linear transformations as nicely as strawberry and cream. then it isn't extortionate to calculate a base point from it where needed.

[iarwain]

thanks for the explanation. I gotta be the one with the craziest input devices as I'm commuting between a touchpad and a tablet.=D

I have to admit I haven't given much thoughts to these control devices yet! ^^

as for the pivot point, I use a central pivot point in my framework. it goes together with halfsize vectors and linear transformations as nicely as strawberry and cream. then it isn't extortionate to calculate a base point from it where needed.

Totally true. However I found that when scaling objects on a grid so as to create levels, a centered pivot point was pretty annoying as both ends "move". Maybe I can go with a central pivot for rotation and a top left one for scale. On multi-touch input devices, the problem wouldn't even exist. =D

Also, the .ini won't teach you how to mirror in the editor, you simply have to scale "negatively" to do so.

EDIT: For the scale, maybe I should just use the "opposite corner" as base point. This might feel even more intuitive when scaling objects.

[György Straub]

thanks for the explanation. I gotta be the one with the craziest input devices as I'm commuting between a touchpad and a tablet.=D

I have to admit I haven't given much thoughts to these control devices yet! ^^

As it turns out, my touchpad is so 21st century, that there IS a mouse wheel on the right side of it, it's just totally inconspicous.=)

as for the pivot point, I use a central pivot point in my framework. it goes together with halfsize vectors and linear transformations as nicely as strawberry and cream. then it isn't extortionate to calculate a base point from it where needed.

Totally true. However I found that when scaling objects on a grid so as to create levels, a centered pivot point was pretty annoying as both ends "move". Maybe I can go with a central pivot for rotation and a top left one for scale. On multi-touch input devices, the problem wouldn't even exist. =D

Also, the .ini won't teach you how to mirror in the editor, you simply have to scale "negatively" to do so.

EDIT: For the scale, maybe I should just use the "opposite corner" as base point. This might feel even more intuitive when scaling objects.

How about keeping the centre point for transformations and using the boundaries for snapping? After all, that's what grids are for?

[iarwain]

As it turns out, my touchpad is so 21st century, that there IS a mouse wheel on the right side of it, it's just totally inconspicous.=)

Nice hybrid you got there! =) At least you can scroll through the assets/layers in the editor now.

How about keeping the centre point for transformations and using the boundaries for snapping? After all, that's what grids are for?

That sounds good in theory. However, let say you've set up your level, including your ground, but you now want to move your right-most wall 4 columns to the right. If you choose now to scale your ground to joint with your right wall, the ground object will scale 4 columns to the right but also 4 columns to the left. Instead you need to make it grow 2 columns to the right, and move it from 2 columns too. With big objects that are larger than the screen, it becomes annoying.
Maybe it's not a manipulation level designers have to do often, but I found myself doing it almost every time I was adding a wall/ground object. But again, I suck at level design so I'm the worst beta tester for my own tools ever. =)

However for the snapping, you're totally right, it should always been done using the boundaries. That's something I need to change. =)

[iarwain]

Didn't have much time to work on this entry for a couple of days, but here what I did:
- Added time weapon (& gravity one, but it's not plugged yet) + associated shaders
- Added health bars
- Fixed a couple of things

Added new bindings: C to jump, X to shoot and Z for the time weapon.

The time weapon is basically a sphere around the player that slowdowns everything in range but the player himself; it recharges over time.

The archive doesn't contain the Mac OS X version yet, I'll update it soon.

Download ProjectX-0.6 here

[the_illusionist]

i'm gettin this error..



i think my computer isn't awesome enough to play your game,or is it?

[György Straub]

i'm gettin this error..



i think my computer isn't awesome enough to play your game,or is it?

me2, and stderr.txt complain was complaining about a shader that could not be compiled. (sorry, Crossover seems to just not support ProjectX, I shall post the error message next time I'm in Windows.)

[iarwain]

Can you tell me more about your configuration? Video card/windows version?

Someone reported a crash on Windows 7 but as I only have access to 32b XPs, I can't do much about it, unfortunately. :/

[iarwain]

i'm gettin this error..



i think my computer isn't awesome enough to play your game,or is it?

me2, and stderr.txt complain was complaining about a shader that could not be compiled. (sorry, Crossover seems to just not support ProjectX, I shall post the error message next time I'm in Windows.)

Oh, shader issue.
Can you go to data/object/Weapon.ini and comment with a ';' the line 18? I'll test the new shaders later on Mac today, hopefully I'll then find the issue.

[György Straub]

Can you tell me more about your configuration? Video card/windows version?

Someone reported a crash on Windows 7 but as I only have access to 32b XPs, I can't do much about it, unfortunately. :/

Windows Vista Home, Pentium Core 2 Duo 2.0GHz, 4GB RAM, ATI Mobility Radeon HD 4570
Windows XP Boot Camp, Pentium Core 2 Duo 2.4GHz, 1GB RAM, ATI Radeon HD 2600

[iarwain]

Thanks for the specs, György!

Apparently the shader compiler on my MacBook is less permissive than the one on my XP computer.
I've fixed the Time & Gravity shaders, hopefully that should fix your issue.

I've updated the v0.6 archive. It also includes the mac version as well.

Please let me know if it fixed it. Also if you can test on Vista, I'd be curious to know if it works correctly on it.

I will now work on score and level chaining. This week end will be dedicated to sound/music integration, if things go well.

[György Straub]

Thanks for the specs, György!

I've updated the v0.6 archive. It also includes the mac version as well.

Please let me know if it fixed it. Also if you can test on Vista, I'd be curious to know if it works correctly on it.

No probs; v0.6 works a-ok.

[iarwain]

Thanks for the specs, György!

I've updated the v0.6 archive. It also includes the mac version as well.

Please let me know if it fixed it. Also if you can test on Vista, I'd be curious to know if it works correctly on it.

No probs; v0.6 works a-ok.

Great, thanks!

[iarwain]

ProjectX v0.7 now contains a temporary splash/title screen (can be skipped by pressing space) and some music/sounds + misc tweaks.

It's a bit "messy" for now, so please let me know what you think should be changed. =)

Archive contains Windows & Mac OS X binaries + source