(3 replies, posted in General)

I see you have sorted it out on your own. I have been away from Surge since it is indeed a great engine from which I learned a lot of game design and development tricks, but it is not naturally fit for my project.
If memory serves me, to make the player vulnerable during a jump you can use either on_player_in_the_air and weak_player together, or set jump to 0 in the chr file and use an object to do on_button_down followed by set_player_yspeed


(3 replies, posted in MODs)

I see great level design here, I suggest we re-skin a few stages for Open Surge


(8 replies, posted in General)

he might not have been the most popular member, but he's been here since back in the days of Open Sonic. It's sad to see him go like this sad


(60 replies, posted in General)

SurgeScript now features a Tag System

so this is the much requested object categorization/object families?

please tell me that after this we get hardware acceleration cool


(60 replies, posted in General)

this looks awesome! I'm anxious for the integration smile

That sounds tempting, although a bit too much for me at the moment. as you know graphics and sound are my main areas. learning C plus a graphical API would be too much to tackle. Perhaps after I'm done with the release of Drift (over) Drive I'll come back to Open Surge with the intent to not only make a game with it, but also to further improve the engine.

did you ever get to understand how Paintown managed to mix Allegro 4 and 5 ?

Sounds great, although I have no idea how to do it. If you can aid me through that's great. I'll set up my compiling environment. Meanwhile, how do I get started with replacing the routines?

After some more tweaking, I managed to virtually eliminate performance issues. of course, too many shaders at once and computer goes kaboom, but still, fun to toy with big_smile

here, knock yourself out cool

https://drive.google.com/open?id=0B_G9c … G8wTThqT1E

EDIT: Image removed (Link expired) Follow link above for full gallery

As some of us know, Open Surge does not support hardware acceleration of any kind.

A few days ago, I was researching wrappers of old graphical APIs and found out that the latest versions of DGVoodoo can wrap DDraw into OpenGL and Direct3D!

Well, this is a wrapper, meaning all functions are emulated and therefore performance suffers a bit. But it worked!

So I went a step further and started toying with ReShade to add some Shader effects. And it worked!! But it was sluggish, veeeeery slow.

It was still interesting, though. Some shaders don't do anything at all because Open Surge renders in 2D, so things that need a depth buffer won't work. But color correction, HQ4x and things that affect the screen rather than individual elements are bound to work.

Not really useful per se, but it was fun, and let me wondering what a world of possibilities an engine based on a modern graphical API could offer smile


(6 replies, posted in MODs)

if you look at the image closely, the character object is playing two animation frames at the same time


(6 replies, posted in MODs)


apparently there is a problem with on_animation_finished, because once i replaced that with a timeout, i haven't noticed any more of this


(60 replies, posted in General)

you don't need to sacrifice those elements. you just have to build the system differently.

maybe those could work as separate objects?


(60 replies, posted in General)

the trick here is not attaching, but creating it and destroying it in very little time.

for example, you have an object called ".homing_target"  which can be created by every enemy at every 0.1 seconds and destroys itself after another 0.1. then you add a state to it where its XY position is written into two globals.

now, every time you need to home in the attack, you use change_closest_object_state ".homing_target" "position" to actually write the variables.

then all the homing attack needs is to check the distance, if it is within the allowed range, and if it is proceed with moving the player to the recorded XY position.


(60 replies, posted in General)

but what if multiple instances exist on screen? they would all want to access the same globals I think


(60 replies, posted in General)

In the old one, you have to change states and pass the position of the parent back and forth.

exactly. the problem with that approach is that the object can not have more than one instance per level, or they will overwrite each other's position globals.

second option is to copy some behaviors from the collider to the actor and sync states, but it appears there is a small delay when passing state changes over the hierarchy. one frame maybe more


(60 replies, posted in General)

I use collision boxes and masks extensively. problem is,  you can't attach an object to another object, only to the player.

do you remember the last screenshots I posted? one of them had this big rat with a club. we will use it to explain my point, as it is the best example I have.

because I can not make its weapon an attachment, it has to be a part of the sprite. if I attack and hit the weapon it gets hurt. if the weapon touches a wall, platform physics trigger a wall collision and stop movement in that direction.

still on platform physics, if any sprite which is meant to move on the floor gets a strange shape computed from its opaque pixels, weirdness ensues. from the shaky walking to clipping through solids.

automatic collision management is a great thing, don't get me wrong! however there are moments where a simple shape is enough to handle physics and interactions and that's where it's useful being able to assign a graphic to it, or maybe in the spr file have an option to apply a simple collision shape and set its size.

something like

rectangle_collision 0 0 32 32
ellipse_collision. -16 -8 16 8


mask_collision images/collision.png


(60 replies, posted in General)

another thing that strikes  me over and over is the way collisions are handled on sprites. while it works good with small and simple sprites, bigger and more complex sprites register collisions at points that even though they are opaque pixels, they are not the core.
just imagine that your sprite has an item  in their hands and an enemy can hurt him by touching only the item. makes no sense .

if we could load a collision mask, I mean an image of the same size as the original sprite sheet but it would have only the parts of the sprite that accept collisions, that would let us have fine control over collisions, without the need to change how collisions work.


(6 replies, posted in MODs)

Thanks Alex smile

OS was never meant to compete with anything, it is its own thing and it is good like that. That's where it shines.

This progress was not achieved without a few bumps on the road: The gravity for objects doesn't work so well and objects making use of it often clip through walls and warp over bricks :\ and another weirdness is a strange animation duplication that happens sometimes even if there is no other object or even the player changing to that specific animation. This is barely noticeable in motion but in a screenshot it's very obviously noticeable. I'm not sure if this has anything to do with the changes I did to the source code, and I'll try to replicate this with a "clean" engine.

I'll also post a few shots soon, so you can see what I mean smile


(6 replies, posted in MODs)

Ambition without restraint is a big killer hmm

I wanted to do and learn so much, in the end, I just learned.
I learned it is better to go for small things when you work alone, and build up on them as you can.
I learned it is better to have a small set of core mechanics and good level design.
I also learned that if you know how a tool works and you're good with it, you stick with it (please don't use this as an excuse to try and turn screws with a hammer lol )

That's why I'm taking a break from Construct and coming back home to Open Surge, and to you guys.

To all the new peeps, hi! Nice to see some fresh meat... i mean friendly new faces lol

Don't get me wrong, Construct 2 is great. I dare even say a lot more flexible and powerful than Open Surge (It's actually pretty obvious). However there is something in Open Surge that no other engine has offered me so far:

  • Easy scripting

  • Based around a state machine

  • An emotional connection ( d'awww <3 )

Enough ranting! As some of you may know (because you actually read my posts or we are friends), I had a troubled relationship with my game, and this time I think I reached the point where I want to actually finish it. For that I had to put a lot of plans in the drawer with the label "too much for one person alone" on it.

And so, I want to announce that the game will be a linear arcade-style beat-'em-up platformer with very simple RPG elements. Sounds more complex than it really is, since basically you walk right (so cliché lol ), fight enemies, pick up power-ups and get stronger as you defeat more enemies. Enough rambling! I have pics to prove it!

Teaser Pics:

Full Album:

https://www.facebook.com/ShinobiDensets … 506312174/

That's it for now. Comments, suggestions, complaints, applications to join, or just trivial chat about the weather, I'd love to know about it!


(60 replies, posted in General)

analog controls are not a must but I suppose that could be done in the migration to A5


(60 replies, posted in General)

in the past I suggested mouse input in-game

one thing that strikes me , is that the current input system only supports legacy usb gamepads and up to 8 buttons per pad.
I think it would make sense to support Xbox360 and ps3 controllers, or at the very least, support legacy analog 12 button controllers, the ones similar to a PlayStation or Xbox controllers.

to open surge this means a fine control over the player's speed. to modders maybe a whole lot more.

is this feasible?


(60 replies, posted in General)

I also ran into a couple issues

depending on local definitions, the decimal separator is either a comma or a dot. in some systems,where the comma is the default decimal separator, variables with decimal values are taken as integer rather than float. this is especially noticeable with values defined in chr files.

another thing is, after updating the exe on a project built under an older revision, some scripts cause a crash to desktop. I was able to isolate the offenders, but not to figure out what's wrong with them. and I'm not talking about migrating from open sonic to open surge, but rather between different revisions of open surge.


(60 replies, posted in General)

so many great ideas big_smile

here's some more

picking entities from a bar or floating window

a menu, bar or window tracking variables for easy access and debugging

object families sharing  variables  across objects, and allowing  things like on_ collision "family"

in properties mode, show a family tree for objects with parents or children and let them be selected from there for debugging purposes

make functions that  for example check for bricks at an offset take  object angle into account or not, through an optional switch in the functions.

along with the upcoming load/save system and corresponding commands, a built-in save point like the checkpoints would be nice for those not wanting to manage their own systems.

again, per player variables defined in their .chr scripts . for open surge would mean things like individual ring counters, scope and duration of player abilities and so on. for mods the possibilities are endless.

that's all for now. I'll find some more wink


(60 replies, posted in General)

Glad to see things moving smile

Regarding the old scripting system I have quite a few things to say. most are indeed related to scripting, others to some things I found in the engine that I believe could be changed for the best.

So, first off we have this: The scripting API is very simple to learn, and allows beginners to quickly implement behaviors into objects in the game. Though simple, it offers also more advanced features like fast loops (which NOTE: will most likely freeze your computer if you don't know what you're doing roll ), retrieving data through internal functions and allowing you to create your own functions with the execute command! It's marvelous, I mean it! Though if I am honest, the engine could be improved and offer users more real-time control of some things.

  • Allowing private variables to be set per instance, in the editor and through scripting

Using parent/child relations to take care of this is exhausting. Why not let the engine assign one ID to each object and display it in the editor? Maybe even showing a little info on mouse hover. maybe the mouse could behave a bit differently, as in today you have modes for group, brick, object and built in objects. how about an "info" mode where you can only click objects to edit their starting properties (variables)?

  • some nitpicks and annoyances

Collision rectangle for the player is hard coded, noticeable in interaction between player and bricks. no matter how big the sprite, the collider fits into a small gap. if the sprite is smaller than this collider, it causes the player sprite to apparently collide with something it is not touching, when in reality the physics collider is doing this.

Background visible in editor, if possible let us set its parameters and load/save BG and BRK from there smile

The possibility to build a brickset just by loading separate images for each brick. maybe a separate tool.

characters should be allowed to stop on slopes. depending on what the creator is trying to do, this might be blessing or damnation. in my case, since i'm not focusing on sonic fangames or games inspired by sonic, it's a damnation. if this could be defined through scripting it would be perfect. you could do anything from slippery ice to spider man cool

it would be nice to have the sonic physics affect every objects using the "gravity" command, because objects don't know how to go over a slope without some workarounds like a "while" loop in the object's script constantly pushing the object up when it overlaps a floor brick.

creating local multiplayer games shouldn't be so hard and require so much working around. I'm not sure how to tackle this, but something like "set_controller playerX" rather than the usual "observe player" and "set_inputmap" BUT don't remove the latter, as it allows for so much more, like objects that manage extra controls or hotkeys.

that's all i can report for now. if I find something new I'll keep you posted smile

I mean, in an on_collision condition, is there a way to know where both objects are touching? I'm not sure what you mean with "bounding box method"