The UWORDs written had too many digits, too large for an Amiga 16-bit number. I encountered this just recently, when adding some code to xiffview that writes Amiga UWORD values to a text file, using something like fprintf("0x%04x", value). Also different compilers on different CPU architectures may have different data storage types - an "int" on a modern x86 machine is not be the same size as an "int" on Amiga. LSB on x86) has been mentioned many times. When writing software that's handles data for different architectures, you have to pay attention to a lot of details. I use it regularly, it has become part of my makefiles, and I add features as I need them. Linux IFF picture viewer xiffview, which was created as a side-product of game development, now really comes in handy. So now it's got a scrollable bitmap, separate status bar, sprites, tiles, game map files, and a rudimentary "physics" engine that allows sideways movement and drops. There are a couple of limitations, but whenever you run low on colors, need a different origin for your drawing coordinates, or maybe are thinking about an alternative to a dual-playfield, a new ViewPort might solve the problem. Einstein-alike.Īnyway - after overcoming these obstacles it's beginning to look like. ![]() The docs give contradictory information about what "reserve" actually means - bit set or clear? It has now been proven and confirmed that bits need to be set to allow VSprite usage of that hardware sprite, and bits need to be cleared to "reserve" the corresponding hardware sprite from VSprite usage. I'll work on compatibility or maybe a separate version of the game later.īasic screen mockup, to get an idea of object's sizes, and screen layoutĪnd a "bug" in the docs was discovered: When using VSprites, you "reserve" some hardware sprites from VSprite usage by setting/clearing bits in GelsList->sprRsrvd. As a quick fix I'm focusing on what is probably still the most common Amiga configuration: Amiga 500, OCS chipset, Kickstart 1.3. Well, after hours and hours of experimenting, it turns out that ViewPort->RxOffset and ViewPort->RyOffset are indeed the correct variables that need to be changed to move around a larger source bitmap, but they get interpreted differently by different Kickstart/OS/chipset versions - it looks as if KS3.0 on AGA chipset, and KS3.1 SetPatch'd by OS3.9 on AGA chipset, might be messing up VSprites when scrolling, and earlier KS versions always scroll by low-res pixels, regardless of actual display (high) resolution. Either way, in the end result some VSprites are missing, or the scroll offset is wrong. At some point you try a high-res display mode. So you read the docs, set up your default, low-res PAL display "View", create a "ViewPort", adjust ViewPort offsets, re-read the docs, adjust the ViewPort offsets properly, read the docs again, re-adjust. The Amiga is a technical marvel, but it has it's pitfalls. I've arrived at VSprites, tiles, and scrolling. Go to AmigaAmp's website to download your copy:Īnother project I've been working on is slowly taking shape, and there was quite some headache involved to get it going. Now using octave-spaced equalizer band frequencies.rexx extension and start with a line saying /* AmigaAMP ARexx Macro */ Popup menu for "Add." button in ReAction playlist window.Snapshot windows directly via pulldown menu entry.Multi-select playlist in ReAction mode. ![]()
0 Comments
Leave a Reply. |