Amos Bugs

Started by Hungry Horace, December 04, 2006, 12:10:00 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Spellcoder

#15
I've started a list of AMOS-bugs too, I try to test them all but my time is limited (working on some other stuff for the WIKI first).
Everyone is welcome to edit the list.
Direct link to the amigacoding WIKI page:

http://amigacoding.com/index.php/AMOS:Bugs

I've noticed the bug with long inputs too once.
At first I thought it hanged/froze your Amiga indefinitly, however a few weeks ago when I
retried the bug I noticed after half a minute the program would resume. (without crashing)

The bug with lots of Data is also in the AMOSPro V2 compiler.
It just crashes during compiling (guru number you get meant that memheader was corrupt I think)

The problem with keypresses on the same row on some Amiga's is in the hardware I think.
AMOS can't help with that :(.

Didn't know (or forgot) about the bug with Add, ages ago I read that post.


edit (feb 2008): updated link

Lonewolf10

Quote from: Spellcoder on October 12, 2007, 07:28:00 PM

The problem with keypresses on the same row on some Amiga's is in the hardware I think.
AMOS can't help with that :(.

Didn't know (or forgot) about the bug with Add, ages ago I read that post.


Yeah, keypress bug is a hardware thing. I never use add anyway (I prefer X=X+1 or Inc X).


Regards,
Lonewolf10


Hungry Horace

#17
dunno if anyone else has come across this when using the LOAD iFF functions of AMOS, but i was getting this wierd graphic glitch, shown here:

http://pspuae.condor.serverpro3.com/images/mlm/bug1b.png



Anyway, although I solved this after a bit of experimentation, whereby i made my picture a bit wider with new width of 352, a wiser man than myself was able to tell me a possible reason:

Quote from: StingRayprobably uses blitter to copy it and can't handle sizes not divisible by 16
which still means: the amos iff loader ****** sucks

Fair point, but i thought i'd post it here in case anyone else encountered the same thing.
Quote from: KillerGorillabecause winuae is made of code and your amiga is made of stuff


Lonewolf10


No, because I haven't really had the need to use predrawn full screen images in any of my stuff yet. Have you added it to the bugs page on Amiga Coding?


Regards,
Lonewolf10


LuisCoCo

Hello friends , I am a new user of AMOS and practicing with amal I realized that in the " IF " possessed "AND " "& " do not work properly, and only the last running on the line, know this bug?

Excuse my English , I was born in Spain

Amiten

Nice and unknow info about Amos here thanks!,

What you think about to start a knowlege List of  Amos Bugs for orhers can avoid?? 

Example:
When we Flip a Bob in amos with $+8000 and other Sides and we stop the program when a flip had been  made and try to modify Add more bobs in the object editor the bob apears flip :( no good because we flip manually in code but not in the bank.

Extrange but like all other bugs or non normaly functions mention here is possible to fix or avoid if we know.

All the best

Enviado desde mi SM-N9005 mediante Tapatalk

AMIGA is a Style of Life

bruceuncle

Quote from: Amiten on July 06, 2016, 08:40:19 PM
Example:
When we Flip a Bob in amos with $+8000 and other Sides and we stop the program when a flip had been  made and try to modify Add more bobs in the object editor the bob apears flip :( no good because we flip manually in code but not in the bank.
This behaviour is what I've classified as "That's the way AMOS Pro works!".  It's not something that will get fixed as a bug as it's the most efficient way for AMOS to do the flip - it uses the already allocated space in the sprite bank in chip RAM.  It could be changed, but would only slow AMOS down as it would have to allocate memory to hold the flipped image, etc.  There are a few other reported bugs that fit this category  :o .

Note that the User Menu in AMOS generally has two versions of each of the Editing Accessories.  The ones at the top operate on banks grabbed from the currently loaded program.  The ones lower down are 'stand alone' and expect to load a file.  You should always regard the contents of loaded banks as volatile (although the image flipping one is the only one that I've come across that changes a loaded bank, but can't guarantee that there might be others  ::) ).  When developing, I always work on the files for banks rather than the loaded copy to be absolutely sure nothing gets changes or corrupted.
Repeat after me ...  "The AMOS Pro architecture is complex but it is not complicated."

Amiten

AMIGA is a Style of Life