RESHOOT PROXIMA III – New game from the RESHOOT R guys

[sandruzzo]

@buzzybee

Enemies system was in its prime stage. It read enemies positions' on TILED map, and put them into linked list. What it's missed its the way to build path from editor side and load data into source. With my code you can decide how many enemies you can generate from one place hold put into map. In fact I look for "object layer"...

[buzzybee]

Originally Posted by sandruzzo

@buzzybee

Enemies system was in its prime stage. It read enemies positions' on TILED map, and put them into linked list. What it's missed its the way to build path from editor side and load data into source. With my code you can decide how many enemies you can generate from one place hold put into map. In fact I look for "object layer"...

So unfortunately no benefits if I switch to your code. I will then keep on working with my own engine, as it is already up and working. It can read and interpret Tiled-data, and spawn objects at defined spots with defined attributes.

[sandruzzo]

Originally Posted by buzzybee

So unfortunately no benefits if I switch to your code. I will then keep on working with my own engine, as it is already up and working. It can read and interpret Tiled-data, and spawn objects at defined spots with defined attributes.

More or less what my source code do!

[Tigerskunk]

Originally Posted by sandruzzo

More or less what my source code do!

Petting Sandruzzos back...

[sandruzzo]

I know for sure that buzzybee is doing a great Job. If hi need hands, I'm here. But like I said, its' a very good programmer...

[Ian]

Originally Posted by buzzybee

[*]Thanks to invent and many other creative active minds here at EAB, with whom I exchanged views and thoughts in the past two days. Got a lot of backing from good people. Decided to get back to participating in discussions only, which have a positive or constructive vibe to them. I knew this makes sense in social media anyway, but forgot it for a moment and took some disrespectful comments and PNs personal.

Grow up.

Not everyone is going to say a flower smells of roses. I don't think it can be argued that the old version doesn't look great, so comments about the appearance should be expected.

Being a moderator is not a job, it's something we volunteer our time to do, sure we don't always get it right for everyone, but as everyone else mods are entitled to their opinion at all times, on any topic they wish to post in, as is any other member.

I think you confuse the EAB with a big internet site like Resetera or NeoGAF were mods are paid and literally only manage the board/create topics etc.

It's not like that here, and it never was. If you don't like or cannot handle some justified criticism, then don't advertise your product on this forum.

[buzzybee]

Originally Posted by Ian

Grow up.

If you don't like or cannot handle some justified criticism, then don't advertise your product on this forum.

See, RESHOOT R took three years to develop, only because of criticism both positive and negative, from people who saw videos or played the game at events. A lot of suggestions made the game what it is now. Same will happen with RESHOOT PROXIMA III.

[Rochabian]

I don't understand why you get excited about this new game in production. Richard took over an ongoing project that was not finalized, where is the problem?
It will be different from the initial project but it will be finished and playable.
If the game does not please you in the end, don't buy it that's all.
We can't blame Richard for creating a new game on Amiga.
Certainly we can give him advice but it is his vision of the game, it's him who has the last word and who chooses whether or not it integrates the comments to his project. Everyone seems to be waiting for THE Amiga shmup. It will be or maybe not, we'll see when it comes out.
If I put in the place of Richard, I would feel a little discouraged by these negative feedback on my creation.
But I also understand people who put a lot of hope in the sandruzzo's initial project

It will not be the same game, better or not.

Reshoot Proxima III will be or will not be THE ULTIMATE shmup of the amiga, wait and see.

And I will continue to encourage richard & invent & sandruzzo on their project

Keep up the good work

[buzzybee]

Originally Posted by Rochabian

... it's him who has the last word and who chooses whether or not it integrates the comments to his project...

But I also understand people who put a lot of hope in the sandruzzo's initial project

If I may interfere: It´s basically invents project. He´s the one who drew the old mockup screenshots and all the visual stuff which fired peoples imagination. Kevin a I, as a team we successfully did two RESHOOT-games already and decided to restart the whole PROXIMA-project after it was basically grounded for many months, because it´d be a shame not to use invents assets. Kevin and I, we exchange ideas and opinions regulary and decide the direction of the project together.

One classic example of a discussion we recently had was about a very basic gamedesign decision: Should background be collidable or have rather aesthetic purpose, framing spawning objects like in many modern shmups. Together we chose the oldschool route ...

Originally Posted by Rochabian

Reshoot Proxima III will be or will not be THE ULTIMATE shmup of the amiga, wait and see.

Same goes for Kevin and me. We don´t know yet how RESHOOT PROXIMA III comes out. We have to wait and work. We aim for greatness :-)

Originally Posted by Rochabian

And I will continue to encourage richard & invent & sandruzzo on their project

Keep up the good work

sandruzzo is not involved. Think he is busy doing other stuff.

Thanks a lot for your encouraging words!

[sandruzzo]

@buzzybee

I can share some tricks that could help, if you don't use yet, of cource

[buzzybee]

Originally Posted by sandruzzo

@buzzybee

I can share some tricks that could help, if you don't use yet, of cource

You mean coding? That´d be nice, any optimization appreciated! What would you suggest?

[sandruzzo]

@buzzybee

Some suggestions that I'm gonna use for MS, I discussed these tricks with Tomaz


- In order to speed up blitter setup, you have to bobs' frames, one by One. One frame One file. You can gain a lot of CPU time, and have blitter setup, more copper frendly

- Another One that i was thinking about, Is to do some sort of variable shading rendering, like modern gpus. One could be turn on off plane far from player. Another Is to run bobs far from it at 25hz. Maybe using less planes with the same way....

- And if we limit bobs at 8 colors we can go up. Not 8 for all bobs, but for each kind of enemies

- For bonuses(Rygar) i,ve used another trick to avoid blitter shift and byte One more word. I've put them to aligned address! We can use that trick for steady bobs or bobs that move only into y directiont. And if we carfully design some enemies we can make them move into aligned boundries and skip blitter shift

- Fast blitting whitout restoring screen for all bobs' that won't overlap
- 3 planes full cookie-cut, + 2 fast ones
- No shift for aligned bobs'
- Screen area 256*192 to have a lot of free dma cycles
- Sprite to do parallax
- Turn on/off planes were we can
- Use less colored bobs for all of that out of focus.

http://eab.abime.net/showthread.php?...ight=sandruzzo

[saimon69]

Is VERY similar to the SBE/SPE trick in Powder; we had some subpalettes of 8,4 and 2 colors for bobs to use beside the full 16 and was moving a bunch of stuff in 25fps

Originally Posted by sandruzzo

@buzzybee

Some suggestions that I'm gonna use for MS, I discussed these tricks with Tomaz


- In order to speed up blitter setup, you have to bobs' frames, one by One. One frame One file. You can gain a lot of CPU time, and have blitter setup, more copper frendly

- Another One that i was thinking about, Is to do some sort of variable shading rendering, like modern gpus. One could be turn on off plane far from player. Another Is to run bobs far from it at 25hz. Maybe using less planes with the same way....

- And if we limit bobs at 8 colors we can go up. Not 8 for all bobs, but for each kind of enemies

- For bonuses(Rygar) i,ve used another trick to avoid blitter shift and byte One more word. I've put them to aligned address! We can use that trick for steady bobs or bobs that move only into y directiont. And if we carfully design some enemies we can make them move into aligned boundries and skip blitter shift

- Fast blitting whitout restoring screen for all bobs' that won't overlap
- 3 planes full cookie-cut, + 2 fast ones
- No shift for aligned bobs'
- Screen area 256*192 to have a lot of free dma cycles
- Sprite to do parallax
- Turn on/off planes were we can
- Use less colored bobs for all of that out of focus.

http://eab.abime.net/showthread.php?...ight=sandruzzo

[buzzybee]

@sandruzzo: Thanks for details. The RESHOOT-engine already supports spritelayers and several other techniques. It´s quite versatile too, so much so that I do not have to live with too many sacrifices in terms of color or moving direction order to implement attack waves. That makes gamedesign life easier for me. Using a view of 256x192 was never an option, I love big PAL-views of 320 x 256.

Also, maybe my approach towards gamedesign is different to yours. To me, its design first and technique second. I envision a game and then try to think about / develop code which makes the ideas happen. Example: I enjoy fast shmups, therefore 50 framerate is a given. In order to fill the screen with action, I make heavy use of sprite layers and one-color-particles, because they are comparably cheap on blitter / cpu and still make the scenery feel lively even with only four to six blitter objects on screen.

One-Word-Blits might come in handy, as there is a lot of vertical movement in a vshmup like RP3. Thanks for the suggestion!

[sandruzzo]

@buzzybee

This one will be like a handy: no restoring screen!

http://eab.abime.net/showthread.php?...ight=sandruzzo

[buzzybee]

@sandruzzo: Link does not work; would you check that? The RESHOOT-engine does not use a dedicated restoring buffer, but tripple buffering. The third buffer keeps background data intact and therefore serves as a restore buffer.

[sandruzzo]

@buzzybee

Gotcha! You need third, which will speed up a lot even regular cockie-cut!

[buzzybee]

Sorry, I don´t understand.

[sandruzzo]

With third buffer, you can skip one operation of double buffer cockie-cut:

from:

- save screen
- blit bob
- restore screen

to:

- blit bob
- restore screen

[DamienD]

Ok, as this thread is now turning into a coding thread... moved appropriately.