New software company/New Amiga game

[Piru]

@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).

[InsaneSoft]

@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

[Piru]

@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? :-)

[Piru]

@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.

[InsaneSoft]

@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

[Flashlab]

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!

[Piru]

@InsaneSoft

Replacing the custom mask bitmap allocation with the following makes the game work just fine under MorphOS:

Code: [Select]


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:

Code: [Select]

APTR isMorphOS = FindResident("MorphOS");

then:

Code: [Select]

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.

[InsaneSoft]

@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