Ashley's Forum Posts

  • Hmm... I looked for a different style, this is the closest to the old design:

    http://demo.phpbb3styles.net/Czar-Orange

    But they don't have it in green for phpbb3... thoughts?

    Or you could have a browse through there and see if you can find a style you like!

  • I think you could actually calculate the direct, quickest route to the player from anywhere with any configuration of platforms using a modified version of the A* pathfinding algorithm. It'd definitely be tricky, but by setting cells which you cannot reach by jumping to an infinitely high "cost" to traverse (ie. impassble), generating special one-way cells for jumping off ledges etc, you could return a list of nodes that lead to the player. The next challenge would be to make the player jump and run accurately through all these nodes...

    Definitely to go in a behavior! That'd be tricky to event.

  • http://69.24.73.172/scirra/wiki/index.p ... umpmapping

    Thoughts, feedback, suggestions etc. here, thanks! Let me know if you come up with some nice effects, this effect is pretty cool

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Looks nicer, more features etc. Hope you enjoy.

  • The forum has been upgraded to phpbb3. Hope you like it

  • I've never come up with my own engine, but an idea: I think nodes are the way to go. If you don't want to go round placing nodes at the edges of all your platforms, then come up with a way of automatically detecting platform edges: place a detector on the floor in front of the object in the direction its heading. When this detector is NOT overlapping anything solid, you must have come to the edge of a platform - so you can set off a jump. This would allow your AI to jump over gaps instead of dumbly charing off the edge in to the abyss, and it's node-free.

  • Yeah you could do it by compositing convex polygons, but not a single concave polygon on its own. I don't think Ellipse in the physics engine uses vertices at all, I suspect it's a custom algorithm, since there are probably specific equations for perfectly round objects.

    The reason is (not that I'm an expert) that it's much harder to write an efficient collision detection engine if you can't guarantee a convex polygon. I'm not sure the specifics why. I think it also applies to a dynamic shadows engine, but I'm not sure.

  • http://downloads.sourceforge.net/constr ... irror=osdn

    Fixes a few of the last bugs introduced by the new renderer in 0.94, as well as new Bumpmapping (using normal maps) and Heightmapping (using height maps) effects, as demonstrated in this thread. Wiki article on these effects can be found here. Here's the full changelog:

    Behaviors

    • [ADD] New Shake behavior to shake objects
    • [ADD] Ability to disable fade on startup
    • [FIX] Moonwalking in 8 direction movement
    • [FIX] Car movement 'Is moving' now also true when reversing
    • [FIX] Platform movement gravity direction & glitches corrected - should all be working fine now!
    • [FIX] Fade can now be activated after already used

    Event Sheet Editor

    • [FIX] System now shows in Vista when families are used
    • [FIX] Objects without conditions or actions no longer shown
    • [FIX] Objects order correctly when adding actions/conditions/expressions

    General

    • [ADD] Bumpmapping and heightmapping shaders (see wiki article)
    • [FIX] Object information dialog

    Layout Editor

    • [ADD] Keyboard shortcuts to select and unselect, and invert selection, CTRL+A, CTRL+U, CTRL+I
    • [FIX] Grid now shows again (new rendering system broke it)
    • [FIX] Objects are sorted alphabetically again in insertion dialog

    Picture editor

    • [FIX] Hotspot/image point tools now display again
    • [FIX] Magic wand tool
    • [FIX] Selection boxes now show

    Plugins

    • [ADD] Window plugin
    • [ADD] Registry plugin
    • [FIX] Texture issues with 3D box
    • [FIX] Memory leak creating/destroying text objects

    Runtime

    • [FIX] Artefacts on object edges caused by new renderer
    • [FIX] Memory issues causing incorrect returns for 'gettoken' expression
    • [FIX] Surfaces bug causing layer glitches (new renderer again)
    • [FIX] Crash mixing 'Pick random' and behaviours

    Script Editor

    • [ADD] Snippets bank (/Snippets/ subfolder) to insert common code
    • [FIX] Tabs not showing in Event Sheet Editor

  • Well whoever said some law about things always going wrong at the last minute, they were right, next build should be out soonish

  • Multiple light sources was in regards to dynamic shadow casting - it's possible with bumpmapping but you essentially need a bumpmap effect for every light, which would probably run too slow for this use. Maybe there's a way I can work out to do that better.

  • You shouldn't use thousands of sprites to do this, it's an inefficient solution to the problem. The best way involves adding something like Attan's suggestion to Canvas, which I've planned for a while, but not got round to. So I'd say wait until then to make your destructible terrains.

  • Polygons could be useful in physics and advanced lighting engines (which we don't have yet), but post-1.0 for these probably - until then box and ellipse will suffice...

  • or you'd be loading it into memory and interpreting it on the fly (which could slow your game down drastically)

    Events are already loaded in to memory and interpreted on the fly, so no big problems there.

    All in all it's a fairly good idea, but I think its a post-1.0 type of idea, considering weighing up benefits and workload. It wouldn't be particularly easy to code, since you'd have to deal with situations like someone saving an event sheet for their platform game and trying to import it to someone's RTS game.

    The main use I see for it is quick patching - if all your events are exported as external files, you can do bugfixes and distribute the small event files as the patch update. Writing mods with this system is trickier since you'd basically need the source .cap to generate a valid event sheet (with the right object names in the right order with the right behaviors and effects etc), which kind of defeats the point - Python would be much better for mods. This patching method also has a number of drawbacks:

    • It's not that far off redistributing the main .EXE for a patch, which isn't too difficult usually.
    • If you want to ADD an object or something, it's useless - go for a normal patch again.
    • If you want to change any of the graphics, effects, behaviors etc, again it's not effective.
    • Even with a 200mb EXE with events-only changes that you want to patch... existing patching tools save differences between files only, so chances are good you'd have a tiny patcher still. And this method of patching has none of the above drawbacks.

    Nice idea, but I think it needs careful design to get around some of these issues.

  • The short answer is no, physics collisions won't be per pixel, because the collision engine in Newton is substantially different - it operates on convex polygons rather than bitmap masks. Also, many bitmap masks are impossible to convert to a convex polygon. I was thinking about adding some kind of polygon editor, so you could at least approximate the object's shape with a convex polygon, but it's probably some way off.