Inviyya - OCS Shoot Em Up

[Tigerskunk]

Originally Posted by roondar

Anyway, on the topic of NTSC vs PAL for Inviyya specifically, it seems to me Steril707 is completely correct: changing the game to be NTSC compatible (and run at 60Hz) this late in development is probably quite a bit of work and would entail a downgrade in number of objects that can be shown on screen. Such choices are best made at the start of the project, not at the end.

I could throw out the sprite parallax.
Would look bad, though..

In any way I could manage to do it, it would always be the extremely inferior looking version compared to PAL.
Who would want to play this?

[Predseda]

[roondar]

Originally Posted by Steril707

I could throw out the sprite parallax.
Would look bad, though..

In any way I could manage to do it, it would always be the extremely inferior looking version compared to PAL.
Who would want to play this?

Just as an idea: it may be possible (though it'd need testing) to allow NTSC mode for accelerated Amiga's or Amiga's with real fast memory and manage to do so without dropping frames*. But I'm assuming that's not really what you had in mind.

Not sure if it's wise to bother with such use cases though. Still think it's probably best to leave it as PAL only for now tbh.

*) Though not many A500's have true fast memory

[Chrille]

I am lucky that I own a real PAL Amiga and that I could run Invyya on it.

But If I would be forced to play that on an emulator with a 60 Hz Screen only, I would prefer a smooth game with full framerate (NTSC setup) without an extra sprite parallax. I am a litle bit allergic to jerky scrolling May be there are other possibitlies to run it with full frame rate on an emulator.

Everyone who owns an NTSC Amiga with an NTSC only monitor would be also happy. It is alway better to run a game without special effects than running no game.

And in case of that you have unlimted time I would like to see an AGA improved Version with NTSC mode and a sprite parallax.

On the other hand if it is too much work, leave it as it is and you could investigate your time in improving the game play. Gameplay is alway more important than these edge cases. Or you could investiagte your time in new projects.

BTW I have not tested the demo yet, I think I'll do this the next days.

@roondar I think that a turbo card and/or fast ram are not enough to run this game on NTSC and sprite parallax. I guess it is all about free dma cycles. I guess AGA would help

BTW how many lines are displayed in this game?

[roondar]

Originally Posted by Chrille

@roondar I think that a turbo card and/or fast ram are not enough to run this game on NTSC and sprite parallax. I guess it is all about free dma cycles. I guess AGA would help

Well, it's a long-shot for sure. But it can't really hurt to try (if Steril707 even wants that - it's his game and not mine, I'm just offering my 2 cents ).

[Tigerskunk]

Originally Posted by Chrille

@roondar I think that a turbo card and/or fast ram are not enough to run this game on NTSC and sprite parallax. I guess it is all about free dma cycles. I guess AGA would help

I was under the impression (seeing how the 1200 operates) that a faster CPU needs less DMA cycles to get stuff done..

Is that wrong?

[roondar]

Originally Posted by Steril707

I was under the impression (seeing how the 1200 operates) that a faster CPU needs less DMA cycles to get stuff done..

Is that wrong?

Yes and no

Faster CPU's take fewer cycles to complete their actions (so say a MULU or DIVS running on the A1200/68020 might be four times as fast as on an A500 with 68000), but any memory access to chip memory they do still requires the same number of free DMA slots. The exceptions are the AGA machines & the A3000, where longword reads/writes can take half the DMA cycles (assuming the address accessed is on a 32 bit boundary).

[Bren McGuire]

Ahh a bit sad to see what's going on here, but I will say one thing: this is why you don't share unfinished work online. The hordes of "experts" come at you telling you all about what you did wrong.

I know that sometimes it's tempting to try to put out your work even if unfinished, because you've been working for so long on it, but this is the inevitable outcome.

I really cannot believe my eyes with what I read here about this demo. It's a demo, of an unfinished game, what the hell are people talking about and judging a full game that does not yet exist because of 1, 2, 4 levels of an early demo?? Talking about the g ame difficulty over a damn early demo? How does this demo represent in any way the full game level of difficulty? It does not!

It's insane, what goes through people's minds, I don't know.

Suggestion to Steril: keep your work in progress distributed among a tight-knit group of people you can trust for feedback, and don't post another demo. Heck, if I was me, I'd remove the current one too. You don't need this extra noise and from what I read on the forums before you almost cancel this project before due to some online bullshit. People like me who appreciate this work don't want that to happen.

I'm happy not playing the game until you decide to fully release it. just watching it on Amigabill's stream was good enough of a teaser for me. Keep up the good work.

[ross]

I disagree.
Spread a demo version it a good way to catch nasty bugs, do tests in very different configurations and collect suggestions.

Annoying people can be easily ignored.

In any case, it does not seem to me that someone has intervened improperly in the requests. All very polite.

The only controversies came from a different thread/board and past things.
And I think Steril707 is clear enough if something doesn't seem sensible to him..

[Predseda]

Originally Posted by Bren McGuire

I'm happy not playing the game until you decide to fully release it. just watching it on Amigabill's stream was good enough of a teaser for me. Keep up the good work.

Actually, the game plays better than what we saw in Bill's stream - there were some strange glitches that I haven't encounter while playing demo.

[Tigerskunk]

Yep, i see this demo as a very positive thing apart from that one incident, where someone thought he needed to tell me he has the right to override my artistic decisions..

All the other suggestions I received have been very level headed, respectful and polite, and from a couple I even got some good ideas.. It's great to get out of your bubble from time to time and get some input from the outside.

[dreadnought]

Originally Posted by Bren McGuire

It's insane, what goes through people's minds, I don't know.

What's insane is getting your knickers in a twist about a fairly standard game feedback & suggestions thread. Because from what I've seen so far that's what people are doing here, me included, and like ross says mostly in a polite and friendly fashion. If there were any "experts" "yelling and judging" I must've missed them.

[saimon69]

Those discussions about feedback are not at all new, whether is homebrew software or FOSS software btw; probably keeping things to the netiquette might work a bit better that simply let things swing (not always possible,though)

[MickGyver]

Originally Posted by Bren McGuire

I really cannot believe my eyes with what I read here about this demo. It's a demo, of an unfinished game, what the hell are people talking about and judging a full game that does not yet exist because of 1, 2, 4 levels of an early demo?? Talking about the g ame difficulty over a damn early demo? How does this demo represent in any way the full game level of difficulty? It does not!

It's insane, what goes through people's minds, I don't know.

Suggestion to Steril: keep your work in progress distributed among a tight-knit group of people you can trust for feedback, and don't post another demo. Heck, if I was me, I'd remove the current one too. You don't need this extra noise and from what I read on the forums before you almost cancel this project before due to some online bullshit. People like me who appreciate this work don't want that to happen.

It is very important to get as much feedback as possible BEFORE the game is released. The developer(s) can then filter the feedback any way they want. The more people that come with similar feedback/ideas, the more weight it has. If only one person (or a few) has an opinion about something, then it can be taken with a grain of salt. The people who has given feedback here haven't "judged" the game, Steril707 specifically asked for feedback. I think we all want the game to be as good as it can be, because we are interested in it, and constructive feedback can help with that!

[Tigerskunk]

Yep, and honestly, I feel the game is already a lot better than the demo is with just the modifications and bug fixes I have done since then.

[nikosidis]

Yes, this is good with the internet age. Easy for devs. to communicate with the audience. Not everyone is like Steril707 though. The Willie brothers never say anything about their games before they actually get released. I'm a big fan of them and the Trap Runner series and other stuff they did. They have lot's of experience and are at least 2 people.
Like you say Steril707, it is not always easy to be your own critic. I know this a lot myself from making music. NickGyver say the right thing. You should listen if many have the same opinion, not so much otherwise. One bad critic or opinion I would not use much energy on.
It is very cool that you now feel the game is improved and I'm looking so much forward to next demo

[Chrille]

Originally Posted by Steril707

I was under the impression (seeing how the 1200 operates) that a faster CPU needs less DMA cycles to get stuff done..

Is that wrong?

What roondar said.

To recap where you could save dma cycles for AGA/68020+ machines:
- faster cpu - Some instrcutions are 2 to 4 times faster. I could give you some examples if you want to or just read the 68020 users manual. And notice that sometimes 2 instructions get fetched by proceesor at once via one single access to memory (e.g. two add.x dx,dy)
- caches (no memory/DMA accesses when in cache). So in general there are less DMA cycles wasted on executing you code even for chip ram only systems.
- 32 Bit reads and writes to chip ram
- also you could enable FMODE=3 (double cas and 32bit iirc) for dma. Then you have to adjust you scrolling routine as you have to handle 64 scroll positions instead of only 16. IIRC I had a speedup in wonderboy in monsterland from 3/50 to 2/50 fps when enabling fmode=3 via Software ActionReplay and may be adjusting some bitplane modulos, ddfstart and ddfstop registers - I might be wrong on my memories because this is more than 25 years ago and I'm getting old (and boring)
- sprites are wider (with fmode=3; 64 Pixel instead of 16 Pixel). So no more need to double your sprites with copper DMA or just use dual playfields on AGA.
- it could be faster refreshing BOBs with processor than blitter. You could unroll a copy loop that exactly fits into your ICache on 68020+. May be if there is fast ram you can also put your level tile graphics into fast ram. So that you can read data from fast ram instead of chipram for refreshing. E.G. in my unfinsished game I had 32*16 tiles and there it was faster with 68020+ than blitter. IIRC even with ChipRam only systems, it took less than a half of the time with processor. But for my game I had the advantage that I used 32*16 px tiles (Longword reads and writes - but I guess you could archive with 16*16 px tiles also a similar speedup).

Also it is easy to switch between NTSC or PAL mode via BEAMCON0 on AGA/ECS.

So judge yourself if the effort is worth the result and what to apply form the above options. I think you could offer on NTSC machines to disable the sprite paralax on OCS/ECS and/or use full effects on AGA. On the other hand the code gets more complex, if you offer dynamic options from a single floppy disk. Or you could offer 2 or 3 different versions (PAL, NTSC@ECS/OCS and NTSC+PAL@AGA) - remember the first ECS to AGA improved versions of games were also cheaply improved version with an extra playfield (e.g Brian the Lion, James Pond II, Fire & Ice) - Might be annoying if you want to fix a bug later. Then you have to retest all versions again and again.

In conclusion i would say better put you efforts in improving and testing the game play and on the other side if you have some fun in playing/coding with aga systems then why not

Now I'm looking forward to the release of inviyya in which form it will be ever released and testing your demo on the next days on my real hardware when i have time.

[MarkBogaard]

Played it yesterday on my amiga 500 and loved it! Any problems I saw have already been stated and for me they were only some little niggles. On my amiga 1200 the game shows a garbled screen just after entering the part that is protected by the big gun in the beginning, and crashes (as in not responding and the text remains on screen) when pressing a button on the title screen with the most text (I have a blizzard 1230 accelerator, maybe that plays a part?).

[TjLaZer]

I just like to run "PAL" games that don't use the whole screen in NTSC mode as it's *normally* faster and it also fills up the screen. When you run a game that doesn't fill the screen in PAL, you get a large black border at the bottom. I am sure a lot of you in Europe know what I mean! In the early days of Amiga, you all had to endure that from American games. Then later PAL versions, which also utilized the whole screen came out, and that was great. Not so much for us, but it's fine today as we can run PAL games fine. On my setups, I can run PAL fine. Depends on the monitor. Some switch to PAL nicely and auto center, etc. Some don't (Amiga 1080)

[Tigerskunk]

Originally Posted by MarkBogaard

On my amiga 1200 the game shows a garbled screen just after entering the part that is protected by the big gun in the beginning, and crashes (as in not responding and the text remains on screen) when pressing a button on the title screen with the most text (I have a blizzard 1230 accelerator, maybe that plays a part?).

The game has been tested on a config like that, so i don't have any idea what is different on your setup here, i am sorry... :/

There are just so many different factors that can play into why a game plays or not on all these different setups. It's kind of horrible, compared to when you are coding to something with a unified setup like old consoles or the C64, for instance..
In the end I can only guarantee vanilla machines, with the notion that the game seems to work right now on most standard setups ->usually<-.