Souverän Soccer [WIP]

[thairacerjp]

great job dudes ! still very impress, keep the good work

[utri007]

Looks good. I would buyt this. Next game could be nice car game where you could use that same routine you use now to move field. There is very few "semi modern" car games for 68k amigas.

Does every 68k game require it's own memory management system? System routines are not good enough?

[Daytona675x]

@vulture
@thairacerjp
@utri007

Thanks guys

@utri007

Does every 68k game require it's own memory management system?

Certainly not but in my particular use case it helps a lot right now. But that's also because it's all WIP, I simply don't know yet how much memory I will ultimately need for game-state X which is why I currently tend to release memory as soon as I don't need it anymore for a particular task, which in turn is the reason why I tapped into fragmentation issues in the first place... When it's all done I will know exactly how much memory I need in which precise situation, so this memory management may become obsolete later again.

Next game could be nice car game where you could use that same routine you use now to move field.

No, this "engine" is designed for its current purpose only, it is not suited for racing games at all.

[Daytona675x]

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

Even though this update maybe doesn't look like too much it actually shows the solution to one of the last major technical hurdles.

- Vertical ball physics added.

- The now eventually floating ball made it necessary to add a dedicated shadow. Actually it's now a black-flicker-shadow system prepared to be used with all objects but so far only the ball got one. Had to rearrange the player / ball palette a bit for optimal blitting performance.

- Occlusion detection (WIP). This is basically about chosing the cheapest blit-mode for the different entities based on aspects like zoom level and potential overlap. Not fully done but partially working already. If you take a close look you can see it selecting masked-blitting for the player at the ball and non-masked blitting for "less-important" objects. The occlusion detection will later also help to optimize the ball handling a bit more (see below).

- Special ball handling under the hood. Due to the whole display setup it is necessary to display the ball by either using a BOB or a sprite, depending on situation. If the ball is flying high enough it's actually leaving the physical playfield's bitmap area and therefore hasto be displayed as sprite. That's because the playfield (which in fact is some sort of 200 level parallax scroller with constant palette changes and the players and ball on top of it) and its bitmaps end where the visitor-crowd starts.
Also, if it's flying higher than some virtual 2 meters - which means that it's flying above the heads of all the players - it can eventually be displayed as sprite to save a blit. Eventually, because that won't work if it's around the bottom goal area because then the goal will overpaint it, thanks to the Amiga's fixed sprite priorities and the fact that I have to use sprite 0 for the ball due to that and other technical limitations (e.g. sprite palette selection). In such a case and in the general case the ball is drawn as a BOB to be correctly occluded by stuff that's in front of it. At least that's true for now, until the occlusion detection is not WIP anymore, then the ball will be displayed as sprite in even more situations. I also had to rearrange the screen's stats- / clouds- / sky- / city-silhouette-palettes so that those wouldn't interfere with the ball-sprite's colors.
At the moment you can spot if a BOB or sprite is being used: the BOB-ball is animated, the sprite is not (yet).

Cheers ?
Daytona675x

[apex]

I was a PlayStation 1 fan from day one to the last days. It was fantastic to see the improvements on the games over the years, without changing the hardware. Same here, it is impressive to see what is possible with this 30 years old chipset. Sadly it was not possible to have a Daytona anno 1992.

[utri007]

Looks interesting. I donated few euros to you for this project. I actually looked Wings Battlefield to buy but is seems to be available only as physical copy and I couldn't find info what kind of games it is as a single player.

[Daytona675x]

@apex
@utri007
Thanks & cheers

@utri007
Was a pleasure to serve you, sir

[aros-sg]

Maybe it's too annoying to code, but a hw sprite does not necessarily need to have fixed gfx data. Theoretically you can at runtime clear to 0 (make transparent) areas in gfx data where other objects are supposed to be in front of the sprite using masks of this other objects. And btw, eventually != eventuell ;-)

[Daytona675x]

@aros-sg

eventually != eventuell ;-)

Thanks, I'll try to remember that - eventually

Maybe it's too annoying to code, but a hw sprite does not necessarily need to have fixed gfx data. Theoretically you can at runtime clear to 0 (make transparent) areas in gfx data where other objects are supposed to be in front of the sprite using masks of this other objects.

It's not just annoying to code, unfortunately it's counterproductive too.

Consider the most simple case which is one player partially occluding the ball. Even for this case you'd first have to fetch the correct mask from the set of animations and zoom levels, then calculate the correct offset in relation to the ball, maybe do some extra stuff like clipping, then, with all that info, create a ball picture out of the original ball-data and the mask.

As you can imagine all this won't improve performance compared to the current BOB solution. Even worse, in reality you can easily have situations where multiple players are partially occluding the ball, so either you have to simplify and lose quality or lose even more performance. In contrast the current pretty trivial solution delivers best quality at low cost already.
No, that good old "mask sprite-date to simulate occlusion" trick really doesn't work here.

Also, the ball is only a very small BOB, so it doesn't really matter that much anyway. If I reliably get the info "ball is not occluded at all" during the quick (wip) occlusion-check then avoiding the BOB in such a case is a nice free extra-gain because I have that ball-sprite support anyway for the reasons explained before. Anything else is not worth it and will have a very hard time beating the simple BOB in terms of performance and qualiy.

[Havie]

Originally Posted by Daytona675x

@aros-sg

Thanks, I'll try to remember that - eventually


It's not just annoying to code, unfortunately it's counterproductive too.

Consider the most simple case which is one player partially occluding the ball. Even for this case you'd first have to fetch the correct mask from the set of animations and zoom levels, then calculate the correct offset in relation to the ball, maybe do some extra stuff like clipping, then, with all that info, create a ball picture out of the original ball-data and the mask.

As you can imagine all this won't improve performance compared to the current BOB solution. Even worse, in reality you can easily have situations where multiple players are partially occluding the ball, so either you have to simplify and lose quality or lose even more performance. In contrast the current pretty trivial solution delivers best quality at low cost already.
No, that good old "mask sprite-date to simulate occlusion" trick really doesn't work here.

Also, the ball is only a very small BOB, so it doesn't really matter that much anyway. If I reliably get the info "ball is not occluded at all" during the quick (wip) occlusion-check then avoiding the BOB in such a case is a nice free extra-gain because I have that ball-sprite support anyway for the reasons explained before. Anything else is not worth it and will have a very hard time beating the simple BOB in terms of performance and qualiy.

Similar issue with Target Renegade. Much as I would love to use sprites, it would be too complicated and time consuming to workout which image was to be put on the screen first and then copy the correct image data into it. Bobs are better, easier and in this case more efficient (in my opinion).

[Gordon]

Nice! Hope you persevere with this

[Daytona675x]

@Havie
Yes. It may be an option in very restricted scenarios (like some classic 2D game character partially occluded by a static wall or so and if you're using sprites for that character anyway) but in this case (and in most other non trivial situations I can think of) it's no good IMHO.

@Gordon
Thanks, trying

@all
Small video update #18

[Daytona675x]

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

The game's sound effects (not music) system has been implemented. "system" is a huge word for what actually is just very few lines of code, but well, it does the job. So far only two effects have been integrated, mostly because I'm lazy and because for now I was actually most interested in checking out if there was any significant performance impact when playing all those sounds (and yay, there isn't ):

1. a simple ball kick sound. This one is played in "smooth" stereo (channel 0 and 1) coresponding to the ball's current horizontal position. My concern was that I'd have to stop the already playing sounds and immediately restart it under certain circumstances like very quick ball passing between two players or so. On the Amiga this would come at a significant performance penalty. Luckily the ball kick sound is short enough so that this isn't necessary.

2. simple stadium sound. Right now it's just one looping sample on channel 2 and 3. The idea is to use channel 2 for team A's fans and channel 3 for team B's fans and then enqueue different samples on the respective channel depending on situation.

The sound "system" already features all required functionality like sample management, enqueueing, stopping, (master)volume changes etc.
Nothing fancy at all, actually only very basic stuff. But even this simple first test version here already delivers quite some extra stadium atmosphere

Note that I sped up video playback x5 during booting and loading.

Cheers,
Daytona675x

[kriz]

Love it!!

[P-J]

Originally Posted by Wavemaker

The game you're basing it on looks like Taito World Cup with the perspective of Striker. Interesting concept

The playfield is really smooth too.

Yeah, this was my impression too. Has the potential to be Striker, but... good

Never get tired of new footy games though. Hope you're able to get this one over the finish line.

[Daytona675x]

@kriz
@P-J
Thanks guys

@P-J
The best comparison and actually my only inspiration is Super Formation Soccer on the SNES, I didn't even know about Striker when I started this project.
Progress isn't particularly fast but steady at least, I'm quite confident But it'll take lots of more time for sure.

[Havie]

Looks amazingly smooth and YouTube Striker (had it with my 1200 I think) and your game looks so much better and smoother. Keep it up!

[Adrian Browne]

Its definitely progressing well- the ball bouncing looks good. About the players graphics and animation- will they be improved? Are they pixel sprites or some sort of sprite scaled sprites?

[Daytona675x]

@Havie
@Adrian Browne
Thanks

@Adrian Browne
There are no player animations yet. Of course those guys will be animated at some point. Being a programmer-artist I already bought the animations I don't know yet when I'll add them. Probably I'll concentrate on the game-logic first.
Technically the players are bobs, not sprites. They are pre-scaled on startup.

[Daytona675x]

New wip video #20

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

Because I didn't have enough time to get into zen-mode for the player AI I decided to do a much simpler yet also very important part of the game for now:

The player animation system and all player-running animations have been added.

The animation drawings aren't final though, it's just my first shot. The anim frames are taken almost 1:1 from a sprite sheet which I bought for the game at project start. These graphics have a black outline which is unnecessary for my purpose and actually kind of disturbs the scaling algorithm, so the quality is needlessly lowered. At some point I'll take my favorite pixel editor and get rid of that outline, maybe for the next wip video Also, for some animations an extra frame won't hurt.

Anyway, all the internals of the anim system and its integration are pretty much done.
All pre-scaling and team-coloring is handled during first load. The player's shadow is now procedurally added after scaling for best quality.

Note that I sped up video playback by x5 during booting and loading.

Cheers,
Daytona675x