![]() |
![]() |
#101 |
Registered User
Join Date: Sep 2007
Location: Stockholm
Posts: 4,377
|
You should read the comments about AGA in the Blitz Basic documentation. They're not suitable for children…
|
![]() |
![]() |
#102 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,438
|
problem with AGA vs ECS is that it's been added afterwards. So you don't have direct access to AGA features like you have for ECS/OCS. And which madman thought that 8-bit planar would be the best & only choice? seriously??? good luck with your project. My proposal for the music still holds (unless Saimon69 chips in)
|
![]() |
![]() |
#103 |
Lemon. / Core Design
Join Date: Mar 2016
Location: Tier 5
Posts: 1,218
|
For arcade game collisions, you should just use bounding box to bounding box collision. I can bet that 99% of arcade games just did this.
For tile collision, you should give each 16x16 pixel tile, a collision value eg: 0 = No collision 1 = Totally Solid 2 = Can pass through but can stand on top of 3 = Deadly to touch etc.. You will find that in most cases you only have to check a few points... for example only check left or right of the character if they are moving in that direction, only check below the player if they are falling etc.. I wish I still had my sources for Chuck Rock 2 and Wonderdog... the collision in there was quite functional, including sloped tiles. |
![]() |
![]() |
#104 |
This cat is no more
Join Date: Dec 2004
Location: FRANCE
Age: 52
Posts: 8,438
|
And you can reduce the box to the minimum to give the player the impression of "shaving it very close"
![]() I didn't know that Chuck Rock 2 & Wonderdog coder visited the forum! Excellent. |
![]() |
![]() |
#105 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Having thought about the player to enemy collisions i will use the boundary box method over the zero fill flag. |
|
![]() |
![]() |
#106 |
Registered User
Join Date: Oct 2015
Location: Landsberg / Germany
Posts: 533
|
Two areas which I absolutely learned to hate when using AGA with RESHOOT R: the way the chipset handles scrolling and color registers.
* As for your scrolling troubles - AGA handles (the scrolling register) BPLCON1 differently to ECS. Make sure you set the PFxH6 & PFxH7 in sync to the bitplane pointers. * Make sure you check your code on real hardware. Some emulators (FS-UAE) handle the bitplan DMA a bit differently than real hardware. This might lead to scrolling, that works on emulation but does not on real hardware. Make sure that you only poke addresses dividable by four into the bitplane pointer registers. * Using the blitter to check collission is a nice approach and I wish you luck that it still fits in without slowdowns when the game comes together. Personally I´d go for collission boxes and / or manhattan distance method, as these are faster by far. Use the 68020s cmp2 command, it´s very useful for this. |
![]() |
![]() |
#107 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
It's surprising what a night sleep and a swim does for you.
I managed to get the scrolling mostly working now after a couple of hours today, there's still a small bug with tiles that have a 0 pixel Y axis but I'm sure I'll sort that. [ Show youtube player ] This scrolling engine is taking up about 80 scanlines of a frame which is more than I would like- plenty of little tricks to be done though. AGA programming definitely comes with complications. A side effect of AGA that I doubt I'll be able to get around is that the display will be slightly to the right, there's not much I can do unless I lose a load of hardware sprites. The arcade display is 256x224, and a standard Amiga display is 320x192 pixels, this allows 32 pixels at either side of the main display to scroll in new tiles into the main display - handy. Now this means I'm having to put the Amiga bit planes into 32 bits wide mode meaning the Amiga transfers long words (instead of words on an A500) from chip ram which gives a big speed improvement. To get an even bigger improvement you can set it to transfer double long words (64 bits), but then I would need 64 pixels at each side of the main display. It is possible to over scan the display to get those 64 pixels but as most ASM Amiga coders will know you then eat into the sprite DMA which knocks out the hardware sprites. Given I'm planning on using the hardware sprites for the large vulture and rhino enemies as they are 64 pixels wide I'm sticking with this display configuration and hopefully keeping the hardware sprites. It wasn't easy doing this scrolling, and I didn't particularly enjoy coding it. it was frustrating and I can understand why others give up on the damn thing and swallow the Red pill/Blitz/Amos - an absolute pain in the arse to be honest. Better times ahead as I will be loading the maps and will building in the sprite engine soon, I'll then be able to see how many sprites I can get on screen. Geezer |
![]() |
![]() |
#108 | |||
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Quote:
Quote:
Thanks for the cmp2 tip - I haven't touched the 68020 yet, it's still native 68000 for now and just hoping vasm optimises stuff to 68020. |
|||
![]() |
![]() |
#109 |
Pixelglass/Reimagine
Join Date: Jun 2012
Location: Athens
Posts: 1,068
|
How do you plan to use hardware sprites? Only for enemies like the rhino and vulture?
Have you considered multiplexing? Rygar's setup is ideal basically, as the game has 3 different lanes (lava, grounds and sky) where enemies appear. So you could have 4 attached sprites as enemies in a single lane and then multiplex those to the other 2 lanes which can give you up to 12 enemies on screen, just using sprites! On the down side it is a fairly complex work to do and 64x64 sprites do cost a good amount of ram, but the performance boost will be signifficant compared to using bobs for the same job. |
![]() |
![]() |
#110 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
|
|
![]() |
![]() |
#111 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
I've always thought that AGA sprites where under appreciated, 64 pixels is a very respectable width. Looking forward to seeing this in action
![]() |
![]() |
![]() |
#112 |
Pixelglass/Reimagine
Join Date: Jun 2012
Location: Athens
Posts: 1,068
|
It's respectable but you can only that much with them with only 8 channels available (which means only 4 sprites in 16 colors) and multiplexing isn't always an option. On the plus side AGA sprites do have their own individual 16 color palette which helps to up the colors on sceen.
Note to Mcgeezer: another thing you could take advantage of, so these monsters could have their own palette ![]() |
![]() |
![]() |
#113 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Can't do this because of the display configuration, it is in 8 bit plane mode with 5 bit planes for fore ground and 3 bit planes for back ground - giving 39 colours to play with, 31 fore ground, 7 background and + 1 shared colour. |
|
![]() |
![]() |
#114 |
Registered User
Join Date: Dec 2014
Location: germany
Posts: 448
|
Just a little idea: As I understand it, you're using a 5 + 3 bitplane setup, with a palette chosen in a way that emulates dual play field mode. Then you're scrolling the 3 background planes with the blitter.
Now, as you have two scroll values for odd and even planes, even if you are not using dual playfield, you could put your scroll value for the foreground into PF1H and for the background in PF2H. After that one foreground plane has the wrong scroll value - you need to compensate that with blitter. In total, you need to scroll only one plane with the blitter instead of 3. There's a drawback: One foreground plane has a different scroll value than the others. If you blitt on all foreground planes, you'd need to compensate for that, which introduces overhead and is an additional source of nice little bugs. But if your game just uses 16 colors for the enemies, and 16 for the foreground colors, you can simply put all BOBs on even (or odd) planes and avoid that problem. It's then a nice and easy way to free some dma slots, esp. as the blitter isn't faster on AGA than on OCS. Oh, and if you're not scrolling the background at 50 fps, you wouldn't win a lot of course. Last edited by chb; 06 August 2018 at 17:36. Reason: Wrong statement, see my next post |
![]() |
![]() |
#115 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
Could be a bit tricky to implement though. While it's busy blitting the back ground I am using the CPU to copy in the tile blocks for the foreground scrolling, I can probably use the CPU to do other stuff as well during that time. Anyway my point is that at the moment I don't know if I have enough frame time to get around 16 32x32x32 bobs on screen at 50hz, I'll know soon enough though. |
|
![]() |
![]() |
#116 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Quote:
I actually tried something similar to a few years back on my A500 but using a 5 bitplane screen, but didn't like the performance it gave me. Might be better on an A1200 though, as it will have a much lower overhead starting the blitter. |
|
![]() |
![]() |
#117 | |
Registered User
Join Date: Dec 2014
Location: germany
Posts: 448
|
Quote:
![]() If you can live with 16 common colors for the bobs (e.g. if they share only a few colors with the foreground) it gets much easier. But probably too much of a limitation graphics wise for a game like Rygar. Scrap that part ![]() Last edited by chb; 06 August 2018 at 17:32. |
|
![]() |
![]() |
#118 |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Tonight I did a bit more work with the maps, they're pretty much there but I need to debug what is going on. I think some of the tiles in the map arn't correctly indexed so I need to make sure I take the correct one that invent supplied to me... no biggy.
[ Show youtube player ] Blitting that large background layer takes up a fair amount of time, so while it's doing that I use the remaining CPU cycles to handle the foreground scrolling. Still room for improvement though. The test to see how many 32x32 sprites on screen will determine if this is a success though, we'll know soon enough. Geezer Last edited by mcgeezer; 06 August 2018 at 22:33. |
![]() |
![]() |
#119 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Quote:
I'm not 100% sure, but that may actually be faster using the CPU. As I understand it, pure block copies are definitely faster using the 68020 - but I don't know how much faster or slower shifted copies are (the 68020 does have a barrel shifter so multi-bit shifts should not be slower than single-bit shifts). Then again, Blitter/CPU running concurrently is said to be the best option on the A1200... |
|
![]() |
![]() |
#120 | |
Registered User
Join Date: Oct 2017
Location: Sunderland, England
Posts: 2,702
|
Quote:
|
|
![]() |
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
![]() |
||||
Thread | Thread Starter | Forum | Replies | Last Post |
Entry: Rygar AGA Edition | mcgeezer | Coders. Entries | 75 | 28 February 2019 20:41 |
On the Ball - World Cup Edition AGA | djcasey | request.Old Rare Games | 4 | 25 January 2013 12:39 |
On The Ball League Edition AGA , Player Manager 2 | StarEye | Games images which need to be WHDified | 11 | 22 January 2010 18:21 |
The Vague #1 AGA-RTG edition is released ! | kas1e | Amiga scene | 12 | 30 October 2007 00:27 |
On The Ball: World Cup Edition AGA | CodyJarrett | request.Old Rare Games | 11 | 27 May 2003 06:14 |
|
|