English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 22 November 2015, 23:34   #61
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by keithbugeja View Post
No, it's more like I wasn't clear enough. Let's say you have a typical side-scrolling shoot 'em up (like R-Type), with right-to-left scrolling; for every block (or tile) worth of horizontal hardware scrolling (say 16 pixels), the whole playfield is copied (blitted) and moved 16 pixels to the left, and a new column of tiles is drawn at the rightmost edge of the screen to fill the empty space.
Blitting the entire playfield is completely unnecessary... you just shift the start of screen memory one word to the right and keep on going. As long as you have a little extra Chip RAM to move into, the image just wraps round and round. Remember memory is always linear, the 2 dimensions of the screen are an illusion.

Quote:
In Blaze, scrolling doesn't happen this way - instead, the screen is composited from tiles each and every frame. Hardware is still used to control the scrolling at the granularity of pixels, but no 'software' scrolling is used, so to speak. The advantage of this method is that the whole playfield could be animated without any penalty in performance. Moreover, since the screen is basically redrawn at each change, one doesn't need to save the portions of background behind software sprites (bobs). The flip side is that the technique is limited in terms of fill-rate, which is why Blaze runs at around 25 Hz.
This sounds like the technique i suggested for converting NES games, since only 2 bitplanes are required there so it may be able to run at 50 fps.

BTW Mr Beanbag redraws the background behind bobs by refreshing from the tile map, it doesn't save the background behind bobs at all. But it only redraws in rectangular regions, not the whole screen.

Quote:
In a later project, I had experimented with decoupling the pixel scrolling from the rest of the rendering, and running it at 50 Hz. This resulted in silky-smooth scrolling, but sprite movement became very jittery (Think Superfrog). For the player sprite, solving the jitter was just a question of using hardware sprites, which are independent of the background, but for the other sprites, I had no suitable solution.
if the other sprites can also be updated at 50fps, there is no problem. Although Mr Beanbag does experience this problem, because the hardware scrolling has granularity of 1/4 pixel horizontally, and of course bobs are restricted to full pixel motions, so sometimes enemy sprites that are chasing the player can appear to vibrate slightly. But 1/4 pixel scrolling is not possible on OCS anyway.
Mrs Beanbag is offline  
AdSense AdSense  
Old 23 November 2015, 00:45   #62
keithbugeja
Registered User

keithbugeja's Avatar
 
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
Quote:
Originally Posted by Mrs Beanbag View Post
Blitting the entire playfield is completely unnecessary... you just shift the start of screen memory one word to the right and keep on going. As long as you have a little extra Chip RAM to move into, the image just wraps round and round. Remember memory is always linear, the 2 dimensions of the screen are an illusion.
Thanks for your clarifications. How would this work for large maps? If, say, I keep moving screen memory to the right, would I not eventually reach the boundaries of allocated memory, independent of representation?

Quote:
Originally Posted by Mrs Beanbag View Post
if the other sprites can also be updated at 50fps, there is no problem. Although Mr Beanbag does experience this problem, because the hardware scrolling has granularity of 1/4 pixel horizontally, and of course bobs are restricted to full pixel motions, so sometimes enemy sprites that are chasing the player can appear to vibrate slightly. But 1/4 pixel scrolling is not possible on OCS anyway.
Thanks again for enlightening me! I hadn't the faintest clue that hardware supported a granularity of 1/4 pixel horizontally. So I might be misunderstanding your answer, but the problem I experienced was not due to spatial resolution but disparity in temporal updates. In particular, the player camera logic was running as an ISR at 50 Hz, decoupled from the rendering, which ran at 25 Hz. The ISR also updated the registers that controlled the start of screen memory and per-pixel scrolling; this made up for the slower map-drawing updates, and kept the scrolling running at 50 Hz. The sprites on the other hand updated during map drawing cycles, at 25 Hz, so every other frame they would move with the scrolling background, giving the impression they were somehow vibrating.

Caveat: Only true if memory serves me well.

Last edited by keithbugeja; 28 November 2015 at 12:43.
keithbugeja is offline  
Old 23 November 2015, 10:56   #63
NorthWay
Registered User
 
Join Date: May 2013
Location: Grimstad / Norway
Posts: 391
Quote:
Originally Posted by keithbugeja View Post
Thanks for your clarifications. How would this work for large maps? If, say, I keep moving screen memory to the right, would I not eventually reach the boundaries of allocated memory, independent of representation?
This is harder to explain in words than showing with a bit of thick string/rope and a tin can.

Yes, if you just keep adding +2 to your bitmap address you will eventually worm your way through all memory. Not good.
If your level has a fixed width and does not wrap around then you only need to add "level pixel width times number of bitplanes" to your screen memory allocation. If your level is 2560 pixels wide in 4 bitplanes then that is just 640 bytes extra.
If your level wraps around then you will need an extra screen buffer that you keep building up while you use the push forward technique already discussed. You typically have a screen buffer twice as wide as the display, push through into the second half, swap to your other buffer, repeat, and go back to the other again. All the time you fill in the non-displayed buffer in small chunks to distribute the load.

(The pysical thing about the tin can is to take the string and begin wrapping it around the can from top to bottom, but as I said(wrote) you kinda need to do it in person to use it to explain sliding screenbuffers.)
NorthWay is offline  
Old 23 November 2015, 11:14   #64
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
@keithbugeja
Again thanks a lot for full source. I'm not sure if this source is the newest version, because I noticed differences with executable in adf. Can you confirm. Thank you

When I tried compile the blaze then my executable is about 100kb not 70kb.

@Mrs Beanbag - about redraws the background behind the bobs. How efficient this technique is ?
Asman is offline  
Old 23 November 2015, 14:38   #65
keithbugeja
Registered User

keithbugeja's Avatar
 
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
Quote:
Originally Posted by NorthWay View Post
This is harder to explain in words than showing with a bit of thick string/rope and a tin can.

Yes, if you just keep adding +2 to your bitmap address you will eventually worm your way through all memory. Not good.
If your level has a fixed width and does not wrap around then you only need to add "level pixel width times number of bitplanes" to your screen memory allocation. If your level is 2560 pixels wide in 4 bitplanes then that is just 640 bytes extra.
If your level wraps around then you will need an extra screen buffer that you keep building up while you use the push forward technique already discussed. You typically have a screen buffer twice as wide as the display, push through into the second half, swap to your other buffer, repeat, and go back to the other again. All the time you fill in the non-displayed buffer in small chunks to distribute the load.

(The pysical thing about the tin can is to take the string and begin wrapping it around the can from top to bottom, but as I said(wrote) you kinda need to do it in person to use it to explain sliding screenbuffers.)
Your explanation was very clear, thanks!
keithbugeja is offline  
Old 23 November 2015, 14:43   #66
keithbugeja
Registered User

keithbugeja's Avatar
 
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
Quote:
Originally Posted by Asman View Post
@keithbugeja
Again thanks a lot for full source. I'm not sure if this source is the newest version, because I noticed differences with executable in adf. Can you confirm. Thank you.
No, you are right, it's not the same. Still, the demo was just a fork that removed the options screen and added a congratulatory message at the end. Unfortunately, I could not find a copy of the actual demo source, sorry.
keithbugeja is offline  
Old 23 November 2015, 15:36   #67
Retro1234
5150

Retro1234's Avatar
 
Join Date: Jun 2006
Location: Sycophantazia
Posts: 3,775
If you can update a whole screen in a frame without scrolling couldnt you redraw parts of the baciground and have some parallax?
Retro1234 is offline  
Old 23 November 2015, 16:30   #68
keithbugeja
Registered User

keithbugeja's Avatar
 
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
Quote:
Originally Posted by Boo Boo View Post
If you can update a whole screen in a frame without scrolling couldnt you redraw parts of the baciground and have some parallax?
I actually tried this, but my implementation turned out to be too slow. If I remember correctly, I had tagged map tiles containing some measure of transparency, to render them using a mask. Rendering without a mask causes the background to be clipped against the border of a tile, even if the tile graphics do not cover all its area. Unfortunately, when I tried this out, the frame rate started suffering (no doubt because of my poor implementation), so I simply dropped it.

I recycled most of the code and used it to simulate foreground objects which partially occlude the player.
keithbugeja is offline  
Old 23 November 2015, 17:52   #69
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
Quote:
Originally Posted by keithbugeja View Post
No, you are right, it's not the same. Still, the demo was just a fork that removed the options screen and added a congratulatory message at the end. Unfortunately, I could not find a copy of the actual demo source, sorry.
No problem.


I have question. How this parallax technically should be done ? It required two blits per map tile ?
Asman is offline  
Old 23 November 2015, 20:43   #70
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
Quote:
Originally Posted by clenched View Post
Assembles fine with VASM Devpac compatible mode. Takes the better part of a second on my PC. Also noticed pressing J repeatedly gives great jumping capability.

WinUAE tests:
- Failed to load at all with Kickstart 1.3
- Loaded OK with Kickstart 2 but mildly glitchy graphics
- A1200 looks fine.
- saw this message on 68000 "FATAL CPU CRASH!" a couple of times.

Maybe I'll try Devpac later and see what happens.
Fine looking game.

EDIT: Using Devpac 3.02, Kickstart 1.3, game looks perfect. Kickstart 2.0 still some slight gfx trouble. Neither showed the fatal message this time. Didn't bother with A1200.
About "FATAL CPU CRASH". Try add dc.b 0 just before label Loop_Data
It seems that devpac automatically add it to align Loop_Data: what is good in this case, because in the code is word access to the Loop_Data. I'm not sure If such possibility has vasm in devpac mode.
Asman is offline  
Old 23 November 2015, 21:31   #71
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 587
Smile

Quote:
Originally Posted by Asman View Post
About "FATAL CPU CRASH". Try add dc.b 0 just before label Loop_Data
It seems that devpac automatically add it to align Loop_Data: what is good in this case, because in the code is word access to the Loop_Data. I'm not sure If such possibility has vasm in devpac mode.
Your suggestion worked. Thanks. Ran and jumped around for about three minutes with no crash. I'm still mystified why the game doesn't load with 1.3. Since the game assembles so easily, maybe phx will see this thread and have a look.
clenched is offline  
Old 23 November 2015, 22:02   #72
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by NorthWay View Post
If your level wraps around then you will need an extra screen buffer that you keep building up while you use the push forward technique already discussed. You typically have a screen buffer twice as wide as the display, push through into the second half, swap to your other buffer, repeat, and go back to the other again. All the time you fill in the non-displayed buffer in small chunks to distribute the load.
Ah! Well that's a different kettle of fish! Games like Mario, Sonic &c typically don't have maps that wrap around, but let's consider that problem...

We can still do it with wrap-around scrolling. Because once we have scrolled sideways by the same number of screens as the height of the tiles (making sure we reserved that much extra memory) all one needs to do is copy the bottom row of tiles back up to the top, and carry on from there. This is assuming we are using a copper-assisted wrap around for the vertical scrolling as well.
Mrs Beanbag is offline  
Old 23 November 2015, 22:28   #73
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
Quote:
Originally Posted by clenched View Post
Your suggestion worked. Thanks. Ran and jumped around for about three minutes with no crash. I'm still mystified why the game doesn't load with 1.3. Since the game assembles so easily, maybe phx will see this thread and have a look.
Hm... What config did you use? It works on my side with A500 config, cycle exact, 0.5 MB CHIP and 0.5 MB SLOW, OCS, 68000 with 24 bit addressing. WinUAE 3.2.0 64-bit version.
Asman is offline  
Old 23 November 2015, 23:18   #74
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 587
Quote:
Originally Posted by Asman View Post
Hm... What config did you use? It works on my side with A500 config, cycle exact, 0.5 MB CHIP and 0.5 MB SLOW, OCS, 68000 with 24 bit addressing. WinUAE 3.2.0 64-bit version.
1 meg OCS CE 32-bit 3.2.0 and just now what you posted. It is probably something simple too. Here is the binary to check.

Last edited by clenched; 24 November 2015 at 00:24. Reason: delete attachment
clenched is offline  
Old 23 November 2015, 23:52   #75
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
Quote:
Originally Posted by clenched View Post
1 meg OCS CE 32-bit 3.2.0 and just now what you posted. It is probably something simple too. Here is the binary to check.
Executable is shorter then my. VASM version uses HUNK_DREL32, my usues HUNK_REL32. So probably HUNK_DREL32 is not supported in kickstart1.3, I guess that must be an option in VASM to generate HUNK_REL32.
Try compile with -kick1hunks and back with result.
Asman is offline  
Old 24 November 2015, 00:27   #76
clenched
Registered User

 
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 587
That fixed it. Thanks again. I think I'll turn all my debugging work over to you from now on.
clenched is offline  
Old 24 November 2015, 10:46   #77
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
@clenched

No problem, If I can then I will help .
Asman is offline  
Old 24 November 2015, 21:49   #78
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by Asman View Post
@Mrs Beanbag - about redraws the background behind the bobs. How efficient this technique is ?
i never benchmarked it or compared it to any other technique, it seemed like the obvious way to write it in the first place to be honest, maintaining a copy of the background seemed like more work for me let alone for the blitter, as well as an extra memory requirement. But it seems to work quite well, i can get quite a lot of fairly large bobs on screen at once without any slowdown.

Not including any CPU time, or time taken to write to blitter registers however, it means only 2 blits per bob (per bitplane) rather than 3 (in the best case - of course when a bob spans more than one tile, it is more blits, but the same total blitted area, i.e. 2 times the bob's area instead of 3 times)

Another way to deal with this issue is to draw all the bobs "behind" the tilemap, as is done in Chuck Rock and other games using that engine. Presumably (i'm guessing) it also maintains a mask as it scrolls on another invisible bitplane, and combines that mask with the bob's mask. That way, to remove the bob we can just blast it off in colour 0 using the same mask again and we don't need to worry about restoring the background at all. But, it does require combining the background mask with the bob's mask in a separate blit, so that is 2 times the bob's area, times the number of bitplanes, plus one additional blit in one bitplane. Also clearing the bob might require more DMA cycles than a straight copy.

It could be possible to do some limited-colour parallax using the above technique though. If the background only uses 2 bitplanes, it might be possible to blit the entire screen every frame, through the foreground mask.

Last edited by Mrs Beanbag; 24 November 2015 at 22:02.
Mrs Beanbag is offline  
Old 25 November 2015, 13:39   #79
Muzkat
Into the Wonderful
Muzkat's Avatar
 
Join Date: Jul 2001
Location: Earthrealm
Age: 36
Posts: 1,282
That looks incredible.
Muzkat is offline  
Old 25 November 2015, 14:20   #80
Asman
68k

Asman's Avatar
 
Join Date: Sep 2005
Location: Somewhere
Posts: 627
@Mrs Beanbag
Thanks for explanation.
Asman is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Game unreleased-Nuxelia- vitux project.aGTW 91 21 April 2017 23:06
Unreleased Amiga Game?? hansel75 Amiga scene 3 05 February 2014 16:01
unreleased game Antheus Tony Landais HOL suggestions and feedback 5 20 May 2013 10:36
Convert my unreleased game to WHDLoad? jimmy2x2x Games images which need to be WHDified 52 16 April 2011 23:20
Once again, an unreleased game is found! dlfrsilver project.aGTW 82 20 October 2008 00:22

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:08.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.31726 seconds with 12 queries