Recreating AMAL in Blitz
Blitz3D Forums/Blitz3D Programming/Recreating AMAL in Blitz
| ||
| Despite its many flaws AMOS on the Amiga had a few nice user friendly features, one being the AMAL animation language. It allowed easy creation of an objects animation and movement based on a simple string of commands that were stepped though on at a time. A simple AMAL command may have read, "Move -100,0,10" which simply meant move -100 pixels on the x axis, 0 pixels on y and at a rate of 10 pixels a second and so on. Using simple strings like this complex movements were easy to make and actually made things like creating boss character movements a lot of fun. I remember a large monkey jumping all around the screen in a rather intelligent looking manor even though he was controlled by a few randomly picked AMAL strings. My question is what would be the best way to tackle this in Blitz? I have my own ideas on the subject but before I mention them I would like to hear how others would implement the system in the most simple and direct manor. Jason. |
| ||
| AMAL used hardware interrupts to maintain smooth animation no matter what, a multithreaded concept. It was also compiled into machine code, bypassing AMOS' interpretation step. No idea how to translate that into Blitz tho'! |
| ||
| Errr, unless I misunderstand... Use the blitz3d command for 'Move' eg. MoveEntity Monkey, -100, 0, 10 You smooth the movement based on PC by using either render tweening or delta timing. Hope that helps, Rhy :) |
| ||
| You do misunderstand Rhyolite ;) You can't really do true AMAL from within Blitz, you need access to hardware interrupts/multithreading like Shifty said. You could emulate it though, but it wouldn't have the same advantages that AMAL used to have like blistering speed. |
| ||
| Ah, ic ;) Well, I don't actualy - but thats beside the point! Hehe, I should keep my mouth shut when I dont understand the question I guess ;) Rhy :) |
| ||
| Thats what I`m interested in, a way to emulate it. Sorry if I wasn`t very clear before. Any ideas as to how to create a similar system, speed is not important just the idea of how to implement it? Jason. |
| ||
| I still have an amiga with amos on it, did some upgrades on it about 3 years ago too no idea how to emulate amal though |
| ||
| Hmm, IIRC all AMAL did was update the coordinates of an object you created automatically. Once you setup AMAL to do the proposed task, it continues by itself without the need to update it every loop. So to emulate it you would be doing the same things that you would normally do in Blitz to move objects during each loop. That is to calculate and update the position of an object. That's all AMAL did really. |
| ||
| I think your spot on. But how to actually implement this in a simple way is the problem. Jason. |
| ||
| Errr, are we not back to the 'MoveEntity' or 'TranslateEntity' commands then?!! Just wrap up all the movement code into a nice little function which you call every game loop? Rhy :) |
| ||
| It`s actually setting up the AMAL like strings\commands that is the problem not the actual execution of them which would very probably be done with the MoveEntity and TranslateEntity commands. You really need to have used AMOS\AMAL to know what I`m getting at. Jason. |
| ||
| I'd say you have a parsing function that reads through AMAL strings and converts them into movement instructions. Indeed, as modern PCs are so fast you could just interpret tham on the fly. eg. a$="M 100,10" Function parse_AMAL(s$) Read token$ ; read one character ; All upper case letters are commands If token$ = uppercase letter Select token$ case 'M' Read parameters x,y MoveEntity x,y End Function You could try setting up a timer based system that calls this every 60th second/scanline. Probably better ot parse the instruction at program start. AMAL worked so well because the AMAL programs were very short, able to be executed in a tiny amount of time, so could run on interrupts without derailing the main thread. |
| ||
| This is the approach I was thinking of but how to tackle multiple commands in one string, "M 100,10 : M -100,10" posses a bit of a problem. Knowing when one part had finished for instance. Jason. |
| ||
| Yes a string interpreter and a once-per-pass function would do it, personally I found AMAL too inflexible for all but one project where I moved a car across the screen like in the CSL game Formula One on the Spectrum. Let's not loose sight of the big picture here, the purpose of using AMAL was speed and certainly not it's ease of use or flexibility. The big advantage of AMAL was speed. AMAL was running in a BASIC language on a computer with a 14Mhz processor. You dont need AMAL ;) Really, you dont ! |
| ||
| 14Mhz! seems something you put on a wrist watch now dont it! My miggy ran on 14Mhz for years . fast enough for me then! hehe Sorry. Topic returned: |
| ||
| You know, I wasn't happy with the 14 MHz figure above so just checked. The A500 was actually 7 MHz. A1200 was 14 MHz. And yes, that A500 could handle 60fps super smooth gaming!! |
| ||
| You check any highend AAA title for the A500 and I think you'll find most games were really running at 25-30fps ;] Scrolling a bitmap around at 50-60fps was a nice and effective trick to cover that up ;] And yes, 7mhz of awesome power. ;] Still an amazing little beast. |
| ||
| Yup, 7Mhz for A500 I remember it, the only real CPU upgrade was to drop in a MC68EC010 processor which got you a little extra oomph without raising the clock speed. On my A1200 I ran a MC68EC030+FPU at 28Mhz which outperformed my A2000 running an MC68030+FPU at 30/40Mhz? because of the 32bit bus on the A1200. Yet despite my upgraded CPU's in most of mine I found Amiga's where dog slow at any CPU driven task. You have to remember at the launch of the A1200 with it's 14Mhz CPU the PC had just launched the 486 at 25Mhz, it wasn't long before the PC had dx4-100Mhz and the Miggy was still crawling along at 14Mhz. I dont recall the CPU in my A4000, I think it's the standard /40 model with an MC68040 at 25Mhz, but the fastest Amiga I got to work on was a MC68060 at 50 or 60Mhz (+FPU) and by then PC's where a quarter the price and already at 90Mhz. The point is, they where dog slow when it came to doing anything on the CPU and there's only so much extra boost you get from a good chipset, if that wasn't true, we'd all be using Apple's right now. |
   |