Souverän Soccer [WIP]

[nikosidis]

Originally Posted by Steve

Looks very impressive. Maybe rename it to 'European Super League Soccer'

Haha, no need for Super League when we get this running

[kriz]

Many years since a high quality soccer game, this looks very cool already.. Keep on the good work all involved

[malko]

Cool playfield scrolling !
The goal seems 'flat'. Do you plan to add some kind of visual depth to it ?

[Daytona675x]

@vulture
@nikosidis
@Steve
@kriz
Thanks guys

@Wavemaker
Thanks! I don't know Taito World Cup and I didn't hear of Striker until somebody recently mentioned it
My only inspiration was "Super Formation Soccer" for the Super Nintendo, which has more or less the same perspective - and from which I took the current temporary crowd gfx...
Souverän Soccer vs. Super Formation Soccer [ Show youtube player ]

@malko
Thanks! Yes, the goal looks rather flat indeed. Better use of the available colors and a slightly different positioning should do.

[Daytona675x]

New progress video #14
https://www.youtube.com/playlist?lis...yr1OhOssiA0axW

Changes and improvements since the previous video:

The whole grass drawing has been fully minced once more. Now the alternating typical soccer grass bars aren't achieved by using two fixed hardcoded 12bit color values anymore but instead consist out of 24bit fully distance faded colors. As a nice side-effect that also sort of cancels out Moiré-like color issues at the distance. You should compare it to one of the previous videos, the quality gain is huge!

Other than that we now got up to more than a whopping 700 colors simultanously on screen instead of the previous 500. And those ugly color stripes in the outer border are gone too.
Under the hood all color values are now variable, nothing hard-wired anymore. I'll probably exploit that in the next video

Some of those changes, especially in the copper-list, gave me some headaches. E.g. suddenly the sprites became a problem - they'd eventually vanish when partially moving off screen to the left - well, the sprite's first row was still where it should have been... Was a timing-trial-and-error orgy to get that right again and of course the results on the real machine differed from the emulation
But was worth it. And while the quality was enhanced a lot, the copper-list actually actually shrank significantly

In other news: the parrot-logo is now HAM8 instead of HAM6 and the 68060 freeze issue has been found and fixed, thanks to Márton for testing!

[vulture]

oh man, that really look better all the time! well done m8!

[Adrian Browne]

Looking good.

[utri007]

This is strategically good choice. There has been virtually no no new sports game, since Eat the Wistle.

[Konrad]

Looks really good. I noticed something, though:
The ball is currently close to the lower half of the screen. Scrolling is bound to it.

When you're playing upwards you have a good sight of the playfield.
When you're playing downwards though you see approaching players very late.

I assume tilting the playfield is a little late at this stage of development. But possibly zoom out a little more ? Or will you move the ball more in the centre at later development stage ?

(Cologne ?)

[Daytona675x]

wip videos: https://www.youtube.com/playlist?lis...yr1OhOssiA0axW

@vulture
@Adrian Browne
Thanks

@utri007
My thoughts were: what would be a technical challenge with a wow-effect while not requiring toooo much boring (to me) stuff like level-design or so, and sth. that doesn't need toooo much artwork or sth. where you can get away with lots of procedural gfx so that even my coder-art skills could be enough.

@Konrad
Thanks

The ball is currently close to the lower half of the screen.

You are right, right now it's a bit too close to the bottom. It should be some more virtual meters towards the far-away goals.

Scrolling is bound to it.

Yes, scrolling is bound to the ball until you reach the playfield's limits. Most likely I'll add some scrolling-de/acceleration to make it appear less "hard" but in general it will remain that way.

When you're playing upwards you have a good sight of the playfield.

That's the nature of things Of course one player has a slight advantage here. But from my experience with "Super Formation Soccer" this is neglectable. And you switch sides at halftime anyway.

When you're playing downwards though you see approaching players very late.

Once the ball has been moved somewhat more "upwards" (which pretty much means just changing one variable and eventually providing another ball zoom level), this should be no problem. Then it will pretty much match "Super Formation Soccer"s ball position, a title with proven playability
However, maybe this can be improved by e.g. adjusting the camera's depth-offset a bit depending on which team currently owns the ball.

I assume tilting the playfield is a little late at this stage of development.

I thought about that too. But there are many extra technical problems to be expected, which will very likely to be impossible to solve without dropping below 50Hz or too much losing quality.

However, ddni came up with the idea of adding a null-modem mode and I'll most likely consider adding that

Cologne ?

Of course, home sweet home

[Daytona675x]

New wip video #15
https://www.youtube.com/playlist?lis...yr1OhOssiA0axW

That video is somewhat different as it shows how I just made optimizing the game much more comfortable.

GCC's inline assembly is quite some pita.
Every line has to be enclosed into "", every line has to be terminated with \n, register names like d1 become %/d1, parameters coming from C have to be listed in a fixed order and cannot be referenced by name but only by their position in that list.

Also, you have to track all your scratch registers by yourself and add those to the so called clobber list at the very end.
When using branches you have to add a b or a f to the target label to tell gcc that it has to branch Back or Forward

As you may imagine this quickly becomes a mess, especially if your parameter list changes because you add or remove something.
Because of that I spent the weekend to get into VSCode extensions because for this game project I'm using VSCode and the great
Amiga C/C++ plugin by Bartman^Abyss.

For stuff like the menus, most precalculations etc. you can easily get away with C++ most of the time.
But sometimes the not-so-brilliant GCC 68k code generator produces such sub-optimal code that asm is your only option if your targets are unaccelerated Amigas.

To work around the gcc inline asm hell I wrote a little extension which can convert GCC-style asm into something more readable, allows me to edit that and then converts it all back, while also adjusting all branches, parameter-references and the clobber list accordingly.
It integrates nicely into VSCode. I simply have to mark the asm code, hit ctrl+F1 to un-gcc it, do my changes, mark everything again and hit shift+ctrl+F1.

Cheers!

[pink^abyss]

Originally Posted by Daytona675x

New wip video #15
https://www.youtube.com/playlist?lis...yr1OhOssiA0axW

That video is somewhat different as it shows how I just made optimizing the game much more comfortable.

GCC's inline assembly is quite some pita.
Every line has to be enclosed into "", every line has to be terminated with \n, register names like d1 become %/d1, parameters coming from C have to be listed in a fixed order and cannot be referenced by name but only by their position in that list.

Also, you have to track all your scratch registers by yourself and add those to the so called clobber list at the very end.
When using branches you have to add a b or a f to the target label to tell gcc that it has to branch Back or Forward

As you may imagine this quickly becomes a mess, especially if your parameter list changes because you add or remove something.
Because of that I spent the weekend to get into VSCode extensions because for this game project I'm using VSCode and the great
Amiga C/C++ plugin by Bartman^Abyss.

For stuff like the menus, most precalculations etc. you can easily get away with C++ most of the time.
But sometimes the not-so-brilliant GCC 68k code generator produces such sub-optimal code that asm is your only option if your targets are unaccelerated Amigas.

To work around the gcc inline asm hell I wrote a little extension which can convert GCC-style asm into something more readable, allows me to edit that and then converts it all back, while also adjusting all branches, parameter-references and the clobber list accordingly.
It integrates nicely into VSCode. I simply have to mark the asm code, hit ctrl+F1 to un-gcc it, do my changes, mark everything again and hit shift+ctrl+F1.

Cheers!

Yeah, GCC asm doesn't seem to be made for humans . Good solution from your side!
Just in case, here are the essential GCC compiler options for fast code:
-Ofast -fwhole-program -flto -fno-tree-loop-distribution

Your latest build looks really smooth! I feel like the grass could look better with less noise. I would mipmap away even all noise on the far distance. Of course, thats just a matter of taste

[hooverphonique]

Originally Posted by Daytona675x

New wip video #15
https://www.youtube.com/playlist?lis...yr1OhOssiA0axW
GCC's inline assembly is quite some pita.
Every line has to be enclosed into "", every line has to be terminated with \n, register names like d1 become %/d1, parameters coming from C have to be listed in a fixed order and cannot be referenced by name but only by their position in that list.

Actually, you can reference them by name. The code below (although for AVR) has a C variable called "mcusr_" which has an alias "mcusr" in the asm code.

    __asm__ __volatile__ ( \
            "pop __tmp_reg__ \n\t" \
            "sts %[mcusr], __tmp_reg__ \n\t" \
            : "=m" (mcusr_) \
            : [mcusr] "i" (&mcusr_) \
    );

[Daytona675x]

@hooverphonique
Thanks, you're right, by placing [xyz] in front of a register assignment, e.g.
[var_name]"a"(var)
you can then use %[var_name] instead of %index.
I didn't know that one. While this is certainly better than %index I still prefer var_name without %[]
But I could extend the back-to-gcc-style part to use that feature!

[Jobbo]

The inline assembler is actually much better than most people realize, it's just harder than you'd expect to get it right.

I recommend reading through the docs carefully: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html

[Daytona675x]

@Jobbo
To be honest, even if it's not the total desaster I thought it was and stuff like %[var_name] exists, it's still so extremely annoying to type and use that I'm happy to have made me that helper extension to never look back.

@pink^abyss
Thanks a lot
For the grass I plan to have different options, especially for people who prefer checker-board grass coloring instead of bars. But I could also make texel size and noise configurable, thanks for the idea!

[phx]

Originally Posted by Daytona675x

To work around the gcc inline asm hell I wrote a little extension which can convert GCC-style asm into something more readable, allows me to edit that and then converts it all back,

Do you really need assembler fragments within a C function? When the whole function is asm you could simply write it with a real assembler of your choice and link the object files.

[Daytona675x]

@phx
Yes, I need that. Usually only fragments need to be optimized and I actually like mixing C with inline asm, I find that much more convenient (now ).

[Daytona675x]

New wip video #16
https://www.youtube.com/playlist?lis...yr1OhOssiA0axW

I've been quite busy recently, unfortunately not so much with Amiga coding
There has been significant progress nevertheless:

• lots of performance optimizations under the hood. However I still need to do more here to always have left enough raster time for the upcoming game-logic plus sound without frame drops. There's still some possible optimizations left so I'm still optimistic that I won't require any Fast RAM at the end of the day.
  
  
• improved memory management. My main test system is a 1200 WHDLoad machine with an ACA030 (which I disable before testing) and a SD-pseudo-HDD with three partitions; the latest game build is run from a CF-card. So even if you boot without startup-sequence you'll end up with lots of Chip-RAM being eaten by all those drive buffers, unless you manually disable the partitions during early boot or decrease their buffer counts after boot to get back some precious Chip-RAM. While my worst-case free amount of Chip-RAM is still enough for the game, it nevertheless suffered from out-of-RAM problems due to memory fragmentation later on. That's why I added a dedicated memory management which doesn't have those heavy fragmentation problems.
  
  
• the grass' color distribution has been improved to make it appear more random.
  
  
• cycle gadget added. Was necessary to put some stuff into the options-screen.
  
  
• adjustable grass texel size. Until now the game used 3 pixel-wide texels (and it still does by default), measured taking the "nearest" grass row at the bottom into account. IMO this is a good choice for good visual quality. But this is just my opinion. Which is why I made the texel-size adjustable from 1 (super-fine) to 5 (retro-blocky).
  
  
• the lower the texel size the more visible the undesired Moiré effects. Therefore optional mip-mapping has been added. This makes the texel-size-1 mode playable without risking eye-cancer
  
  
• while the game internally features a localization system since day one, it wasn't before now that I actually exposed it by providing a language toggle (english and german so far).
  
  
• ambient color scheme system prepared, only noon and evening so far, I'm lazy.

Cheers!

[vulture]

Looks really good