22 November 2015, 22:34 | #61 | |||
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
Quote:
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:
|
|||
22 November 2015, 23:45 | #62 | ||
Registered User
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
|
Quote:
Quote:
Caveat: Only true if memory serves me well. Last edited by keithbugeja; 28 November 2015 at 11:43. |
||
23 November 2015, 09:56 | #63 | |
Registered User
Join Date: May 2013
Location: Grimstad / Norway
Posts: 865
|
Quote:
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.) |
|
23 November 2015, 10:14 | #64 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
@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 ? |
23 November 2015, 13:38 | #65 | |
Registered User
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
|
Quote:
|
|
23 November 2015, 13:43 | #66 |
Registered User
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
|
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.
|
23 November 2015, 14:36 | #67 |
Phone Homer
Join Date: Jun 2006
Location: 5150
Posts: 5,875
|
If you can update a whole screen in a frame without scrolling couldnt you redraw parts of the baciground and have some parallax?
|
23 November 2015, 15:30 | #68 | |
Registered User
Join Date: Nov 2015
Location: Birkirkara, Malta
Posts: 13
|
Quote:
I recycled most of the code and used it to simulate foreground objects which partially occlude the player. |
|
23 November 2015, 16:52 | #69 | |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
Quote:
I have question. How this parallax technically should be done ? It required two blits per map tile ? |
|
23 November 2015, 19:43 | #70 | |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
Quote:
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. |
|
23 November 2015, 20:31 | #71 | |
Registered User
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 771
|
Quote:
|
|
23 November 2015, 21:02 | #72 | |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
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. |
|
23 November 2015, 21:28 | #73 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
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.
|
23 November 2015, 22:18 | #74 | |
Registered User
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 771
|
Quote:
Last edited by clenched; 23 November 2015 at 23:24. Reason: delete attachment |
|
23 November 2015, 22:52 | #75 | |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
Quote:
Try compile with -kick1hunks and back with result. |
|
23 November 2015, 23:27 | #76 |
Registered User
Join Date: Sep 2008
Location: Gainesville U.S.A.
Posts: 771
|
That fixed it. Thanks again. I think I'll turn all my debugging work over to you from now on.
|
24 November 2015, 09:46 | #77 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
@clenched
No problem, If I can then I will help . |
24 November 2015, 20:49 | #78 | |
Glastonbridge Software
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,243
|
Quote:
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 21:02. |
|
25 November 2015, 12:39 | #79 |
Into the Wonderful
Join Date: Jul 2001
Location: Earthrealm
Age: 43
Posts: 1,432
|
That looks incredible.
|
25 November 2015, 13:20 | #80 |
68k
Join Date: Sep 2005
Location: Somewhere
Posts: 829
|
@Mrs Beanbag
Thanks for explanation. |
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 | 96 | 14 January 2024 14:40 |
Unreleased Amiga Game?? | hansel75 | Amiga scene | 3 | 05 February 2014 15:01 |
unreleased game Antheus | Tony Landais | HOL suggestions and feedback | 5 | 20 May 2013 09:36 |
Convert my unreleased game to WHDLoad? | jimmy2x2x | Games images which need to be WHDified | 52 | 16 April 2011 22:20 |
Once again, an unreleased game is found! | dlfrsilver | project.aGTW | 82 | 19 October 2008 23:22 |
|
|