Jump to content
Sign in to follow this  
madaxe

Need help to test on a Real Atari

Recommended Posts

Hi friends;

As some of you know I'm converting to Atari a little game that I made for Amiga, PC and Speccy. As I don't own an Atari I'm using the Steem Emulator.
I made a little program to test some enemy attack waves and it seems to run very smoothly on Steem, but when I run it on Steem SSE or Hatari there is a lot of flickering.
So, if you have an Atari and don't mind to test the program to see if it runs smoothly I would appreciate.

Note: I'm using GODLib so I think it only runs on TOS 2.06.

 

Thanks in Advance,
José Mário a.k.a MadAxe.

 

Steem screenshot:

steem.png

 

Hatari screenshot:

hatari.png

 

waves.zip

Edited by madaxe

Share this post


Link to post
Share on other sites

Very bad idea to use that GODlib (have no clue what is it, but is unholy for sure 🙂 ) - you automatically lose 90% of potential testers on real HW - and of course when it is finished same %-age of players.

So, I tried it with Steem 3.2 and immediately saw error:  BadMasking.thumb.png.01d4c57c13ddf2ca95636782ce690fc1.png

 

Your code does not mask ship sprite properly .  Tried in Hatari 2.1, and since it offers their EmuTOS at start I said, OK, let's see with it - and what the Hell ! First time that I say something good for EmuTOS - it works !  Yuppie !   There was NO flickering, but large sections of screen were black, complete full width, about 30-40 px high blocks.  And after it really no need to bother with Steem SSE ...

Flickering is almost sure because your Hatari video is not synced with video of your PC.   But the real problem is in your code.  Most likely it just missing syncing of display content generation with V-sync.  In other words, you draw sprites in bad moment(s), and that's why it may missing.

Usual way is to wait completion of drawing to screen - so have complete screen, and then activating wait to V-sync. When it happens switch video address - yes, draw should go in invisible video buffer.  Just to add that bad sprite masking seems as not related with this - that should have some OR-ing with content at that place ...

Maybe you should rather try this with STOS ?

P.S. why sincos - are later levels in 3D ? 😁 

  • Thanks 1

Share this post


Link to post
Share on other sites

Hi ParanoidLittleMan;

 

Quote

Very bad idea to use that GODlib (have no clue what is it, but is unholy for sure :) )

LOL! GODLib is a library for Pure C that provides lots of graphical functions to code games.

http://rg.atari.org/source.htm

 

Quote

you automatically lose 90% of potential testers on real HW - and of course when it is finished same %-age of players.

Yeap, you are right. You were the only good soul that replied me :)

 

Quote

So, I tried it with Steem 3.2 and immediately saw error: Your code does not mask ship sprite properly.

Yes, this is only a test for enemy movement and the masks are not set yet, but I think this should not be the problem.

 

Quote

Usual way is to wait completion of drawing to screen - so have complete screen, and then activating wait to V-sync. When it happens switch video address - yes, draw should go in invisible video buffer.  Just to add that bad sprite masking seems as not related with this - that should have some OR-ing with content at that place ...

I think you are talking about double buffering and yes, I'm using double buffering. I guess you are right when you say that there is something out of place in my code. I'll review it to see what is out of place and what's missing. Thanks for the tip.

 

Quote

Maybe you sho uld rather try this wit h STOS ?

Well, I code in C for the last 25 years and to use Pure C + GODLib seemed to be a very good option. But in fact STOS and GFA Basic captured my attention :)

 

Quote

P.S. why sincos - are later levels in 3D ?

Ah no, the Sin and Cos Table are used to get the sinoidal and circular movement of the enenies :)

 

Sorry for my bad english and thank you very much for your great help :)

Share this post


Link to post
Share on other sites

You are full of right, ParanoidLittleMan. In fact, is no good practice to make a game that only few can play.


Fortunately not all is lost: the version of GODLib that I was using had a bug on an asm routine that did the trap calling for malloc. That caused some trouble in TOSes<2.06.
Now I have the new version, the bug is fixed and GODLib run on all TOS :)


By the way: take a look on my "algorithm" and try to find what I'm doing wrong:

 

Screen_Swap
VSync
Assume Logical Screen
Erase stuff from the screen
Draw Sprites on the screen

Edited by madaxe

Share this post


Link to post
Share on other sites
On 7/3/2019 at 8:20 PM, ParanoidLittleMan said:

Try with Vsync first, then Screen_Swap .


Thanks for your feedback, in fact Vsync first and then Screen_Swap works better :)
And here it is: the new version of Enemy Wave Attack that now runs on all TOS and the masks are set properly. I tested on Steem and Hatari and it runs smoothly with no flickering but a test on a real Atari would be nice :)

Cheers,
José Mário Machado.

waves.zip

Share this post


Link to post
Share on other sites
23 hours ago, ParanoidLittleMan said:

Tested on Mega STE - TOS 2.06, from partition D - where copied your 3 files in one DIR . Works fine 😀

Just in emulator with TOS 1.04 and from ST image file - worked well.

Very nice, thank you for your feedback. I'll do my best to make a simple but enjoyable game... I hope :)
When I have more stuff ready I will put it here in the forum to be tested :)

 

Thanks again,

José Mário Machado.

Share this post


Link to post
Share on other sites
20 hours ago, ParanoidLittleMan said:

Just to add that tested on Mega ST with TOS 1.04 UK and De, and was good too .

 

Thanks 😀

Edited by madaxe

Share this post


Link to post
Share on other sites

One question: Blitter or not Blitter?

 

I know that blitter is a late addition to Atari ST but I don't know if it was very popular among the coders and if was used in many games.

As you can see in the example attachaded when the blitter is On the sprites move faster.

Should I use the blitter as default or autodetect? Or maybe no blitter at all?

My game has about a maximum of 20 sprites at the same time.

blitter.zip

Share this post


Link to post
Share on other sites

Surely is best to use autodetect. That's how it is done in some games, and I used it in case of Giana Sisters with scroll when blitter is present.

 

Unfortunately blitter is not much used in Atari ST(E) games, even if it appeared in 1987. So, could say that was not much popular among coders. Maybe there were no really good docs available in those early years ?

Share this post


Link to post
Share on other sites
On 7/18/2019 at 3:14 PM, madaxe said:

Should I use the blitter as default or autodetect? Or maybe no blitter at all? 

My game has about a maximum of 20 sprites at the same time. 

blitter.zip 48.83 kB · 3 downloads

IMO its worth to support the BLiTTER,

This chip is still available in some shops (bought one last week) and also a lot of users use emulators where you can easily turn it on.

 

 

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...