MajorLunaC wrote:

I get the feeling there's a reluctance to do anything except sticking to a set plan, which has sadly ended up not doing much of anything (no offense). Some projects plan a lot but execute a little, while others plan little but execute a lot. Planning is a very good idea, but it looks like it's been lots of planning with little execution, especially with such strict requirements. At this point, there's not much you can lose by accepting using any assets you can and dealing with the results later. I would say it's better to just use a large portion of the better assets already available, as a collection, and make a story out of that. Some of the greatest stories have come out of improvisation and imagination using inspiration. If you want, the current story can be Part 2 or 3 made at a date when it's possible or better supported. I really like this project and want to see it achieve something great. I'll try to help whenever I can, although the techniques above are very easy and very quick.

no one ever said this better. agree 100%

52

(4 replies, posted in General)

create an invisible object
place it at the player (if that's where the camera center should be)
request_camera_focus
do the shake movement, preferably with elliptical_trajectory
drop_camera_focus when finished
destroy.

53

(9 replies, posted in General)

Just a little update, to an otherwise defunct topic, I found the "secret" behind this effect, and it has to be implemented at engine level.

http://www.extentofthejam.com/pseudo/

54

(1 replies, posted in General)

I removed the ledges completely in my modified engine. if you can compile it, then you got everything working. The exe has that too, but I believe the resolution is wrong.

Unfortunately I stopped working with Open Surge completely, so I don't have the needed tools and dependencies.

If you follow my guide and download the zip file with all libraries for MingW, you should have no problems. Just make sure the folders are going to the right place. I did it one time after formatting and it worked at first try.

Things like the character's collision box are not configurable, and even in the source code are hard to find, and not configurable in a per-character basis.

I hacked many things but could not find a way to properly change that :\

FL Studio works in Windows and Linux+Wine

In Linux you also have LMMS which is a bit similar to FL Studio and is completely free. Not sure if it has a Windows version, but is worth a look, because it's free.

Alexandre wrote:

On the bright side, svgmovement has made impressive efforts towards porting Open Surge to Allegro 5. All on his own. I'm going to take it from there and port it to mobile.

I am probably not alone when I say "please keep us posted on the A5 progress, and let us test it"

Alexandre wrote:

Heck, with emscripten and asm.js, it's technically possible to port Open Surge to HTML5.

I always wondered how that emscripten thing worked. Maybe I'm not on a level to understand, and I would probably lack the skills to do something useful, but the idea to convert parts of Open Surge and adapt them to other language or engine is not totally impossible.

i don't have any problems. maybe it was temporary.

libloadpng is different from libpng. with Synaptic you should have no problems finding and installing all required libraries.

60

(6 replies, posted in Game assets)

*THAT* is REALLY COOL

one of the best drawings of Surge so far. It could be the box art or used for promoting the game.

yeah the resolution can only be changed that way. i will see about compiling a new exe in low resolution.

the physics for objects are far from perfect and you need a lot of "execute" on your scripts, and even then a lot of glitches can happen.

the only way to really control two players at once is by modifying the source code. I don't even know why such a feature is not official, since all it requires is to remove a part of the code, and causes no undesired effects. Like many other features that could be added with little effort...

You can use my exe, or even adapt from my project as needed, but i warn you, the physics behave a bit different, the resolution is 2 times higher, and many other things may be or behave differently from vanilla Open Surge. And you get a neat BG preview in the level editor wink

with this, you need to make 2 players, we'll call them for now P1 and P2.

you need to create two inputmaps in input.def one for P1 another for P2

the companion object for each player should set_inputmap P1 or P2 and immediately change_state or destroy.

with this you have separate controls for each player. you need however to find a solution for the camera, as one of the players will be able to leave the screen.

if you need more help post your questions on how you use it.

https://www.dropbox.com/sh/ft0927hdakmf … kOKna?dl=0

just click the blue "download" button and "download as zip"

have fun! smile

Well, those are good news. And please bear in mind that I am not talking about those tools only for modding purposes. Even if you start the project over and focus on Open Surge the game, not having tools for semi-automated or assisted sprite, brickset and background script creation, is probably going to consume more time and keep the contributors at a distance.

Hey all,

The summer is over, and as most of us know, for student types that means free time. Alexandre is a student, but it seems as though he had no free time.
Meanwhile the community was also mostly stopped. Nothing about the game or engine was discussed (at least at a deep level), no assets were created, and the few active members were working only on their own things, which is not to blame, and is not bad at all.

The reason for this post is exactly that: Is Open Surge, as a whole (engine & game), frozen?

The community is since long not excited or much involved, and I believe that has many reasons, and one of them is actually how hard it is, for a non-coding type to integrate its creations in the game.

I really believe that before we focus on levels and gameplay and engine features, we should make it easy for content creators to put something in the game.

Let's take bricksets as an example. Bricksets have come a long way, since the hand-scripted solution, to the automatic-but-not-so-sensible RBE 1 & 2, to the both tools that bridge the gap between human and machine, the quasi-obsolete brickset tool for Open Sonic, and the new brickset creator, which I believe it is the right tool for the job.

Sure it could have some of RBE's automated features, but it does the job pretty well and lets the user choose the brick order, which is very important when working with many bricks.

For sprites, well, sprites are a pain, as there are no sprite tools AT ALL. It's an endless routine of typing the script, checking coordinates, running, testing, and repeating until you get it right. That's a huge time loss, and very demotivating for artist types.

Backgrounds fall in the same category. At least, by reloading the level you refresh the BG, but it's still unclear, with a given set of XY coordinates and scroll factors, where the image will land, especially because there is no preview in editor.

This is one of the many reasons why loyal users such as me are moving on to more advanced engines, and also the content creators are not inspired and/or motivated: The pipeline is too complex and time consuming.

I hope this is taken as constructive. I don't mean to say, by any means, that Open Surge is trash or archaic. But unfortunately, it won't make a big impression when there are better alternatives.

PC's actually had that processing power long before, but the engine was not optimized (and still is not) to take advantage of the graphics card.

Unless the engine gets updated to Allegro 5 or converted to some other API which supports graphic cards, i'm not seeing it happen soon. The summer is almost over and the engine has not been updated since months, which may mean Alex is hard at work studying how to jump to Allegro 5, or he just has a pretty busy life.

Whatever it is, I believe we will not see any new features soon.

66

(3 replies, posted in General)

what is the value of "gravity" in your character's .chr file? mine is 2 or 2.5, and it works when the cloud has minimum 32 pixels height. Alexandre explained to me once that when the character falls too fast the cloud platform can not hold it if it is too thin. But unfortunately, I also have no idea where the code for clouds is, I tried before to fix it or at least understand the logic, but couldn't find it...

67

(3 replies, posted in General)

I had a similar problem some time ago, but only with cloud bricks. The solution was to make them thicker. I don't know if that's the case, but for obstacles it's better to have at least ~~16 pixels and clouds ~~32 pixels of thickness. Also even if the player sprite is invisible or completely transparent, the player shouldn't fall through solids...

68

(1 replies, posted in General)

Das ist ja toll big_smile

Thanks!

69

(5 replies, posted in Off-topic)

actually the site is outdated. the sources are currently at r.765 while the builds are at 760. So, thanks asirnayeef23 for compiling the latest build smile

It doesn't bring much new, but it fixes a few bugs.

70

(7 replies, posted in General)

did it compile without errors?

can you post a screenshot of your folder, so we can see which files you have?

71

(5 replies, posted in General)

it should improve the deceleration, especially at low speeds, so that, for example, when you are walking slowly to the left and then press right, the character will not suddenly walk fast in that direction. A little hard to explain, but it means you get more precision and it does not feel so much like walking on ice.

72

(5 replies, posted in General)

oh, that deceleration, i think that's in the engine code. something like friction or frc. The controls are a bit twitchy, I hope that gets reviewed later in a release, because as it stands now, we must create scripts to handle some details, and that's not how it should be, in my opinion.
I had some problems with deceleration myself, and I had to create a set of hack scripts to give me full control over the player's movement, which is not actually fun.

This is what I did. Copy to a new text file inside the objects folder, and rename it speedhack.obj.

// ---------------------------------------------------------
// *Object Name:* speedhack
// *Author:* Fracture
// *Designed for:* Shinobi Densetsu
// *Description:* Controls and hacks player's deceleration. further than what the built-in multipliers allow.
// *Version:* SD Alpha 1
// *Last modded by:* KZR, date undetermined
// ---------------------------------------------------------
    
    object ".speedhack"
    {
    
        always_active

        state "main"
        {
            hide
                        
                        let " $stop_threshold = 32"
            let " $multiplier = dt()*player_direction()*128"
            let " $multiplier2 = $multiplier/1.5"
            
            on_player_in_the_air "main"
            on_player_brake "main"
            
            on_button_down "left" "check"
            on_button_down "right" "check"
        }

        state "check"
        {
            on_player_in_the_air "main"
            on_player_brake "main"

            on_button_up "right" "decel"
            on_button_up "left" "decel"
        }

        state "decel"
        {
            on_player_brake "main"
            on_player_in_the_air "main"

            on_button_down "left" "check"
            on_button_down "right" "check"

            let " $speed = player_xspeed()"

            if "(player_angle() > 45) and (player_angle() < 315)" "main"

            if "abs($speed) < $stop_threshold" "stop"
            if "abs($speed) < 128" "decel_half"
            if "abs($speed) < 270" "decel_normal"
            if "abs($speed) < 270" "decel_double"

            change_state "main"
        }

        state "decel_double"
        {
            on_player_in_the_air "main"
            on_player_brake "main"

            on_button_down "left" "check"
            on_button_down "right" "check"

            let " $multiplier = dt()*player_direction()*128"

            set_player_xspeed "player_xspeed()-$multiplier*2"

            return_to_previous_state
        }

        state "decel_normal"
        {
            on_player_in_the_air "main"
            on_player_brake "main"

            on_button_down "left" "check"
            on_button_down "right" "check"

            let " $multiplier = dt()*player_direction()*128"

            set_player_xspeed "player_xspeed()-$multiplier*1.5"

            return_to_previous_state
        }

        state "decel_half"
        {
            on_player_in_the_air "main"
            on_player_brake "main"

            on_button_down "left" "check"
            on_button_down "right" "check"

            let " $multiplier = dt()*player_direction()*128"

            set_player_xspeed "player_xspeed()-$multiplier"

            return_to_previous_state
        }

        state "stop"
        {
            on_player_in_the_air "main"

            set_player_xspeed 0

            on_player_brake "main"

            change_state "main"
        }

    }

You just make the companion object for your player do:

create_child ".speedhack"

Your topspeed values in the .chr file are probably different than mine. You may need to play with this section:

if "abs($speed) < 128" "decel_half"
if "abs($speed) < 270" "decel_normal"
if "abs($speed) < 270" "decel_double"

It's also not guaranteed that my script works 100% like you wish, since my engine is heavily modified, but give it a try and let me know if the player behaves better smile

By reprogramming SD I ran into a few challenges. Some I solved by scripting, others by changing the sources. Unfortunately, I can not do all on my own, so here goes:

  • Improvements to "walk"

I believe that due to the way the sensors handle bricks, slopes are treated like walls, and the object turns around, even when the floor has a slight angle. I was able to script a better walking routine, but this has to be done in a per-object basis and is very time consuming, as it must be adjusted to fit every new sprite.

  • Optionally give "complex" physics to an object (like the player has)

In this case, an object would accept the same physics as a player, given by a command or property.

  • Define if an object can be paused or not

This would allow scripted menus to run while the game is paused, for example.

  • Rotation, Alpha and Scale being compatible with each other

Self explanatory. Maybe new commands with combined functionality, like "alpha_rotate", "alpha_scale" "scale_rotate" "alpha_scale_rotate".

  • Adjustable player hitbox

The hitbox that handles collisions with bricks does not scale with the size of the player sprite. My sprite was 64px tall, but the hitbox was always ~~24px tall, and ducking didn't matter to that. I suggest that we can change it, either by defining it in the .chr file or in an object script.

------------

Some I did myself, but I don't know how to commit them. Alexandre, you have access to my code, you may copy or recreate as needed:

  • Drawing objects behind the background, when Zindex < 0

  • Background preview in editor

  • Drop the old player rotation code, as it bugs when something attached to the player is set to rotate with the player. It also looks smoother.

74

(5 replies, posted in General)

i can not say 100% sure right now, but I believe that the spindash is controlled by a script. somewhere in the objects folder there should be a script for spindashing.

to change player speed variables, it's easier that you change the .chr files. you can then have different values for different characters, and you don't neet to recompile the engine.

For the resolution, though, that's the only way. You should also change the screen size somewhere in level.c, if memory does not fail me.

75

(7 replies, posted in General)

actually i have the same problem. opensurge_bin does not run.

It's better to compile it from the source code. Download the sources and follow the instructions in readme.html. Like said in another topic, you may need to download some libraries, to that i recommend a package manager such as Synaptic. Just see what the results of cmake are, and download the missing libraries.