Amiga.org
Amiga News and Community Announcements => Amiga News and Community Announcements => Amiga Retail News / Sales => Topic started by: InsaneSoft on April 14, 2007, 04:20:40 AM
-
We are very happy to announce you our engagement for the Amiga platform and the release of our newest software title
Amijeweled RTG
Do you like puzzle games? Amijeweled is an addictive puzzle game and you will like it for sure. Build rows and columns of three or more diamonds by swapping adjacent diamonds. If you manage to build a row or column of three or more diamonds of equal color this way, they will vanish and the diamonds above will fall down into the gap. For every row or column you will get points and, depending on the game mode, more time.
Play Amijeweled against time, if you seek the really big challenge. Or advance from level to level playing the level mode, get as much points as possible and try to win against the absolute king of Amijeweled, Dr. Braun!
Amijeweled is available as full version for only EUR 7,-, if you choose the email download. Additionally, you can choose a CD version for only EUR 12,- which will be sent to you by mail, within a very nice hardcover.
Of course you will find a demo version of Amijeweled for free download on our pages, too.
You can play Amijeweled RTG with almost every fast RTG-equipped Amiga, please test with the demo version, if your machine fulfills the requirements.
Please, visit us at our homepage, we are looking forward to you!
With kind regards
Insane-Software Wolfgang Hosemann
www.insane-software.de
-
Thats happy news! Always good to see active development for our platform. :)
-
Goooooooood!!! cool news,nice to view new games to
run and enjoy on our platform.
Where is the correct link to download the demo?
Aweb can't download from the game's page.Why?
And with Ibrowse can the demo be downloaded?
Greetings #Ivanhoe# The legend of the Middle Age.
-
Hello Ivanhoe!
Thank you very much for your praise!
You will find the link to the demo version on the Amijeweled description page, on the right side.
AWeb breaks because of a simple single line of JavaScript needed for the download links. IBrowse 2.3 will do fine, we used it for testing the site functionality for usage with Amiga browsers.
With kind regards
Niels Schapke & Wolfgang Hosemann
Insane-Software
www.insane-software.de
-
Nice game!
I tested the demo but on my system there's graphic corruption in P96. In the FAQ only CGX is mentioned...
Also maybe the filling of the playing field could be faster.
-
Crashes badly on MorphOS, just after opening a black window without frames.
-
Thanks, cool with new projects!
I like it, but I miss faster drawing of the playfield aswell.. Ran ok on my P96 A4000.
And what about fullscreen?
-
Hello!
We think it is time to answer some questions that araised the last day. First of all regarding the crashes under MOS (and DSI on OS4, we think they share the cause) and second to the speed Amijeweled can possibly reach on certain machines.
@krashan: Please, raise the stack amount within the tooltype section of the Amijeweled icon to 75000 or more. We discovered, that the DSI error some OS4 users were faced with, has its origin in a low stack space under certain circumstances. Maybe that Trance needs some more stack to run Amijeweled, please try higher values, too, if the amount of 75000 does not cure your problem. Please drop us a note, if this cures your crash problem!
@Flashlab: Could you please give us some more information about your system, e.g. used graphics card, exact version of P96 and such. We are seriously interested in having Amijeweled running flawlessy on as many different machines as possible.
The speed "problem" has its cause in the relatively slow Zorro bus. The falldown of the diamonds seems to be easy done, but it really isn´t. It is indeed the most power demanding part of the animations. We managed to get it playable even on Zorro2 equipped machines, but it will not be a speed wonder. This is the price we had to pay for the animated truecolour graphics. Machines like the PPC equipped Amiga 1200 or 4000 with a BVisionPPC/CyberVisionPPC will fill the field much faster, even with a 68040/25 (the slowest option for this type of machines). In fact, these machines are as fast as our WinUAE system (1,6GHz Centrino) that we use, among others, for developing and testing.
Fullscreen mode is planned for possible successors of Amijeweled.
With kind regards
Niels Schapke & Wolfgang Hosemann
Insane-Software
www.insane-software.de
-
@InsaneSoft
Maybe that Trance needs some more stack to run Amijeweled
Trance does not affect stack usage at all.
If the game requires more stack, maybe it should have stacksize check + StackSwap when required?
-
Great news!!!! :-o
Thanks for classic amiga support.
-
worked perfect on my csppc/grex4000D amiga! great, gonna see if I can register!
bah, I must add funds to my debit card LOL :lol: :lol: :lol: :lol:
-
Hello!
It is time again to keep you up to date. We are still working on the DSI/crash problem, it discovered being very difficult, sadly.
@piru: We would be really glad, if it was that simple. We are using automatic stack extension already, but we didn't know that this works for 68k programs on MOS. For OS4, there is no automatic stack extension facility for 68k programs, so we were forced to set the stack amount within the tooltypes additionally.
It showed, that this "solution" only works temporarily, after some starts (on some machines two, on our own machine more than a dozen, without a DSI!) Amijeweled still brings a DSI error on OS4, so we think, that Amijeweled will still crash on MorphOS. Sadly.
We contacted the JIT authors to get some help with this. As soon as this problem is solved, we will inform you and our customers about this. Any necessary updates will be sent to our customers immediately, as well as the demo version update will appear on our server.
@keropi: We are very happy, that Amijeweled gives you the fun we intended :) Thank you very, very much for your praise!
With kind regards
Niels Schapke & Wolfgang Hosemann
Insane-Software
www.insane-software.de
-
@Insane Software
I use OS3.9 BB2 with a PicassoIV running P96 2.1b. I do have system enhancers/hacks running like Visualprefs, Birdie and some others...
Does the full version also come with music?
And last but not least, maybe you could make the program in such a way that filling the playing field animation when you go up a level is optional?
-
@InsaneSoft
We would be really glad, if it was that simple. We are using automatic stack extension already, but we didn't know that this works for 68k programs on MOS.
It works, of course. It would be really silly to break that.
-
@InsaneSoft
Debugged the thing a bit:
Avoid using custom planar bitmaps and it works just fine. Why are you using those in a "RTG" game anyway? It just slows the RTG system down as it must c2p/p2c all the time!
You could even use WriteLUTPixelArray IMO (doesn't P96 have cgx emulation for this too?).
Some other observations:
- You should not use scr->RastPort.BitMap->Depth directly, but GetBitMapAttr(scr->RastPort.BitMap, BMA_DEPTH).
- Using MEMF_CLEAR for every single allocation is a bit dull. In case the initial contents of the memory doesn't matter, it could be left out.
- Using 65536 byte array in decrunch and deflate routines accounts for most of the huge stack usage. This could be avoided quite easily with dynamic memory allocation (or static buffer and a semaphore).
-
@piru:
Edit: Thank you very much to point us at the scr->RastPort.BitMap->Depth thing... we discovered some very interesting discrepances between the file on our server and the file an our harddisks.
regarding this:
> Avoid using custom planar bitmaps and it works just fine. Why are you using those in a "RTG" game anyway?
Huh? We are using AllocBitMap() with BMF_MINPLANES|BMF_DISPLAYABLE flags set for allocating the on screen bitmaps and WritePixelArray() of cybergraphics.library to make up the bitmaps from the decompressed image data. If planar bitmaps occur for the colour graphics, one could think that your RTG install is broken oder CGFX bears some serious errors. Maybe you watched the blit masks?
There is _nothing_ custom in our graphics routines. All things are done using OS calls exclusively.
---
Do you know a better solution to allocate the rasters for the blit masks? We would be glad to know, if such a solution exists, that stays compatible with the RTG systems (P96/CGFX interchangably).
We allocate rasters by determining if a "friend bitmap" (speak: colour bitmap) possibly is interleaved (can happen under rare conditions), then allocating memory for the raster according to this result and InitRaster()ing the raster finally.
@flashlab: Do you use a 15bit screen mode? If yes, switch to 16Bit. We had a customer using P96, who got problems with 15Bit. It seems, that 15Bit modes have some problems with P96 on certain machines, for CGFX and OS4 machines als well as most WinUAE installs 15Bit modes work fine. We tested it with a Amiga 1200 equipped with CyberVision64/3D, too.
With kind regards
Niels Schapke & Wolfgang Hosemann
Insane-Software
www.insane-software.de
-
@InsaneSoft
If planar bitmaps occur for the colour graphics, one could think that your RTG install is broken oder CGFX bears some serious errors.
There is a code that allocates a BitMap with AllocMem(), then fills it, and allocates planes with AllocRaster(). It gives you a bitmap with planes in chip memory. This is really bad performance-wise, any CGX bitmaps should really be fast memory. The routine also has some weird bits that attempts to build interleaved bitmap (and fails, the "interleaved" bitmap you build isn't detected as one, the only way to get true interleaved bitmap is to use AllocBitMap()).
BTW., how could WriteLUTPixelArray() be of help, if the program is designed for colour depths >8 bit?
Well I kind of assumed you do blit some palette indexed gfx, too. If you don't, then forget this call.
Sorry, we don't know, where you made this observation exactly, as we already and _only_ use GetBitMapAttr() for determining the screen BitMap depth attribute? It appears only one time, btw. and that is for the window init time.
There's some 4 or 5 locations it's used, and yes it appears to be the code at init. It just looked a bit weird, considering all other things used the proper GetBitMapAttr() call.
Which, as we know in the meantime, is the reason for the crashes and DSI errors. We think, that it is a question of a major redesign in order to avoid the JIT compilers breaking for this routines. But we were not aware, that this routines, as simple and portable they are written, are such a problem for the JIT compilers of the PPC OSses.
MorphOS JIT compiler Trance has no issues with these routines whatsoever. So "PPC OSes" refers to OS4 I guess? :-)
-
@InsaneSoft
Do you know a better solution to allocate the rasters for the blit masks? We would be glad to know, if such a solution exists, that stays compatible with the RTG systems (P96/CGFX interchangably).
IMO the best solution is to use AllocBitMap() to allocate any bitmaps, but mask bitmaps are a bit special case indeed. I'll look up the recommended way after work.
-
@piru:
We would have been glad, if the solution using AllocBitMap() would have worked... but interestingly, CGFX allocates the bitmaps in a totally different way than P96 does. On the same machine, btw. ;-)
The routine you spotted as failing by non-interleaved BitMaps is the one allocating the raster for the blit masks. It indeed doesn´t fail, if the friend BitMap is not interleaved, it allocates a linear memory space for the mask raster in this case.
Our reference to PPC OSes originates from crashes we got reported by MOS users. It crashes right from the start and as OS4 has got some DSI quirks with it (and we do not own a MOS machine), we draw some conclusions. Maybe, we are wrong, but what else could be the error making Amijeweled crash on MOS?
We thought that MOS is a little more compatible to 68k machines than OS4, but that wasn´t right, it seems. Nonetheless we urgently want to have Amijeweled running fine on MOS, so if you could help us with this issue, we would be very glad about it.
With kind regards
Niels Schapke & Wolfgang Hosemann
Insane-Software
www.insane-software.de
-
I'm using a 16 bit PC screenmode already unfortunately...
Edit:
I tested the program with a 24 bit mode and it works fine then! Unfortunately I don't run 24 bit all the time; takes too much memory from my lousy 4Mb of graphics ram...
Also the filling of the playing field is much faster in 24 bit!
-
@InsaneSoft
Replacing the custom mask bitmap allocation with the following makes the game work just fine under MorphOS:
struct BitMap *allocmaskbitmap(struct BitMap *bm)
{
return AllocBitMap(GetBitMapAttr(bm, BMA_WIDTH),
GetBitMapAttr(bm, BMA_HEIGHT),
8,
BMF_CLEAR | BMF_MINPLANES,
NULL);
}
void freemaskbitmap(struct BitMap *bm)
{
FreeBitMap(bm);
}
Obviously the one other function using custom bitmap building should use similar AllocBitMap() aswell.
If you want to make the code conditional, you can detect MorphOS with:
APTR isMorphOS = FindResident("MorphOS");
then:
if (isMorphOS)
{
/* mos code */
}
else
{
/* regular code */
}
NOTE: Depth 8 is recommended here to workaround issues in some MorphOS versions, at least if the mask is built using WPA8/WCP family functions.
-
@piru:
Thank you very much. If this really helps to get Amijeweled running stable under MorphOS, we are a step further.
We will build a version of Amijeweled tonight using this special distinction, test it with the help of some MorphOS users and provide an update of the demo version on our server as soon as possible.
Again, thank you very much!
With kind regards
Niels Schapke & Wolfgang Hosemann
Insane-Software
www.insane-software.de