Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Retail News / Sales => Topic started by: InsaneSoft on April 21, 2007, 10:25:38 PM
-
We are very happy to provide you a new version of Amijeweled. It is V1.1 and should solve most known problems, first of all the start problems with OS4/WinUAE (many, many thanks go to Almos Rajnai for guiding us to this nasty bug!).
Further, a new feature is a drastically reduced stack demand of Amijeweled. It should run now with a stack of 8192 bytes. We achieved this by a major rewrite of the decruncher.
Additionally, the full version bears a new highscore feature. It directly jumps to the appropriate highscore list within the title screen after entering the highscore, so you don't have to wait such long time to see your highscore in the list.
MOS users have to wait a bit more, we are very sorry. Amijeweled crashes for totally unknown reasons within the level mode, just when switching to a higher level. Amijeweled starts now on MOS (thanks go to piru of amiga.org), but it is not really playable yet. We are very sorry for this!
Customers already received the update for their full versions per email, the new demo version is available for download at our internet site right now.
Customers who ordered a CD version the last two days, or will do so today, will receive the CD with the newest version of Amijeweled on it.
If you want to have a look on the CD and its cover in advance, please visit our forum at
http://support.insane-software.de/index.php?topic=7.0
With kind regards
Niels Schapke & Wolfgang Hosemann
Insane-Software
www.insane-software.de
-
Spotted another bug, the game calls dos.library/Exit() instead of stdlib exit(). As a result tons of system resources get leaked, for example if the game is started from shell.
Ok. I think I found the lock problem. From the exec.doc/WaitIO:
WARNING
If this IORequest was "Quick" or otherwise finished BEFORE this
call, this function drops though immediately, with no call to
Wait(). A side effect is that the signal bit related the port may
remain set. Expect this.
...and, in couple of places you use Wait(1 << timerport->mp_SigBit) + GetMsg(timerport) + SendIO(timerio).
Since the WaitIO() can leave the signal set, this Wait() will get signal from the previous timer completion, and GetMsg() will return NULL. This means the actual IORequest is still active. Further SendIO() for the already active timerrequest nukes the system (regardless: it appears that the same timerequest is SendIO()d twice).
Quick fix would be to just WaitIO() instead of GetMsg().
[EDIT] It is verified now: I wrote a small runtime patch to fix the code, and I no longer get the lockups. [/EDIT]
Alternatively/additionally: to avoid getting the bogus signal, you could SetSignal(0, 1 << timerport->mp_SigBit); after each timer WaitIO(), making sure the signal is not left pending.
Finally, the game has a buggy CreateExtIO routine. It sets the ioreq->io_Message.mn_Node.ln_Type to NT_MESSAGE, when it should set it to NT_REPLYMSG. (This is possibly from some linklib, perhaps some VBCC provided one?)
-
a really good game this one! , addictive as hell.
Rock on! , me laddos.
-
Cool a new game, don't see many of these anymore:-)
-
This new version don't fix the graphics trouble I had with the previous version in 16bit modes. But as it works fine in 24bit it's no biggy!
I was wondering now that I played the demo a few times. Do the gems always have the same starting order? Also in the full game?
-
@flashlab:
Hmm, we really don't know, what the graphics problem you have could be, except a driver problem. We had implemented piru's suggestions regarding the mask bitmap allocation already and it works without any problems on most P96 machines (in fact we got reported such a problem from you only :( )
Do you use the latest P96 package?
Regarding the diamonds in the demo version: Yes, for the demo version they're all the same at every new start for the time trial mode. The normal mode provides three of the levels of the full version and the same filling diamonds pattern as the one of the full version.
For the full version, the time trial mode gives completely random diamonds, even the filling ones. The normal (level) mode gives fixed diamond patterns, too (as we want to have the same conditions for all level play lovers).
@piru: Thank you very much again for your debugging work. We have implemented the last changes you suggested regarding the timer WaitIO() (we choose the SetSignal() option for this) and await the feedback of our MorphOS testers.
The faulty CreateExtIO() indeed links in from vc.lib. We will replace this with CreateIORequest() from exec.library.
With kind regards
Niels Schapke & Wolfgang Hosemann
Insane-Software
www.insane-software.de
-
just regged! :-D :-D :-D