English Amiga Board


Go Back   English Amiga Board > Coders > Coders. General

 
 
Thread Tools
Old 21 January 2018, 10:28   #61
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,107
Quote:
Originally Posted by Samurai_Crow View Post
Sprites 3, 5, and 7 must be kept blank, otherwise they will act as the most significant bits of the attached sprites.
You just have to make sure they don't overlap. Otherwise you can use all 8 sprites with 6 color reigsters (instead of 12).
phx is offline  
AdSense AdSense  
Old 21 January 2018, 22:23   #62
malko
Registered User

malko's Avatar
 
Join Date: Oct 2017
Location: CH
Posts: 607
Just discovered this thread and enjoyed reading it.
You were not starting from scratch but what such a great progress you made !!!
Finally, coding is like bicycle (once learned you never forget it)
malko is offline  
Old 21 January 2018, 22:33   #63
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 307
Quote:
Originally Posted by malko View Post
Just discovered this thread and enjoyed reading it.
You were not starting from scratch but what such a great progress you made !!!
Finally, coding is like bicycle (once learned you never forget it)
Thanks

Coding was done entirely from scratch. Gfx is from the arcade though.

Quick update to say the game over sequence is now sorted and most of bomb jack’s physics are in place - still bugs though so will do a video once sorted.
mcgeezer is offline  
Old 23 January 2018, 16:01   #64
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 307
OK so decent update this one as I now have a very crude playable game of Bomb Jack working.

Have managed to get Bomb Jack's physics working quite well, even have the modifiers (push up on the joystick for more lift and down for faster fall) working to a degree.

What I'm pleased most about here is the end sequence as it really was the most difficult to get going... not so much the GAME OVER sequence or Jack's death sequence, it was more about gluing the two of them together.

Apologies as this one has no audio, my next update will have and hopefully a good run through of levels 1-5 working. It's really about play testing what I have now and ironing out odd bugs here and there.

After that it will be on to the enemies so in between a bit of coding I've been learning a fair bit of trigonometry - amazing what I didn't learn at school.

Anyone who wants to help play test for me to identify bugs please drop me a PM.

Here's the video - Enjoy.

[ Show youtube player ]
mcgeezer is offline  
Old 27 January 2018, 01:14   #65
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 307
OK, another update here - mainly as promised from my last post with a run through of the first levels but with the great tunes added from @saimon69.

Quite a few fixed bugs too.
Fixed all the bombs being redrawn after losing a life
Fixed lots of Jack's physics issues
Fixed annoying issue where bomb collection would get out of sync
Fixed issue with Jack death sequence
Fixed issue with Game Over sequence

Still lots of small GFX issues to fix

There are two major optimisations I plan for the next couple of weeks that require what I would call a lot of core changes to the code - in other words they are tricky.

The first is the Blitter plot routine is slow, it does 5 blits per sprite. If I adjust the display modulo of everything I can get away with just one Blit per sprite which would be a major improvement. Doing this though may have memory implications as I need to keep 5 copies of the sprite masks in memory and at the moment memory is way low - I need to squeeze this into 0.5Mb of Chip Ram.

The second is the hardware sprites. In game I don't use any hardware sprites, however they are really going to come in handy because after I tried the game on my real A500 it became obvious that I hadn't been using Cycle exact timing in emulation.... in other words... when I had 8 enemies on or more I was getting lots of slow down on real A500 hardware.

Thew video here is with Cycle exact on... emulating closer to what is the real hardware. Due to memory constraints it is 1MB Chip, and 0.5Mb Fast in development mode.

There won't be an update for a good few days as I have some important stuff coming up... but hey ho... this is life.

As always... enjoy the vid.

[ Show youtube player ]

P.S. The game is brutally hard, it's stupid that I can't even pass level 5 of my own game hahahaha
mcgeezer is offline  
Old 28 January 2018, 08:35   #66
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 556
A middle ground if you use interleaved bitplanes is still do one blit per plane (only one mask needed), but a single blit to restore (or clear) the background (no mask need).

But yeah, if you can spare the chip ram, single interleaved blits are a big performance gain.
alpine9000 is offline  
Old 28 January 2018, 10:45   #67
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 307
Quote:
Originally Posted by alpine9000 View Post

But yeah, if you can spare the chip ram, single interleaved blits are a big performance gain.
I wonder how Andrew Braybrook was able to reset the mask pointers during mid blit. I might take a look in his code before i make my changes.
mcgeezer is offline  
Old 28 January 2018, 11:06   #68
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 556
Quote:
Originally Posted by mcgeezer View Post
I wonder how Andrew Braybrook was able to reset the mask pointers during mid blit. I might take a look in his code before i make my changes.
Got any links to this?
alpine9000 is offline  
Old 28 January 2018, 11:20   #69
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 307
Quote:
Originally Posted by alpine9000 View Post
Got any links to this?
Apologies i must have misread his blog.

Here is what he wrote...

In order to use the blitter most efficiently for plotting objects on screen in one 'blit', we had to supply mask data for each bit plane, which would necessarily be identical to the other bit plane masks. Otherwise you have to reset the data pointers to the one supplied mask for each of the 5 bit planes, so you had to do 5 consecutive blits. That was inefficient because you had to wait for the blitter to finish each bit plane before starting the next, whereas if you blit all 5 bit planes in one go then you can be preparing the next object's plotting data while the blitter does its job. So it was the old fight of space versus time.

Boooooo
mcgeezer is offline  
Old 28 January 2018, 11:28   #70
alpine9000
Registered User

 
Join Date: Mar 2016
Location: Australia
Posts: 556
Quote:
Originally Posted by mcgeezer View Post
Apologies i must have misread his blog.

Here is what he wrote...

In order to use the blitter most efficiently for plotting objects on screen in one 'blit', we had to supply mask data for each bit plane, which would necessarily be identical to the other bit plane masks. Otherwise you have to reset the data pointers to the one supplied mask for each of the 5 bit planes, so you had to do 5 consecutive blits. That was inefficient because you had to wait for the blitter to finish each bit plane before starting the next, whereas if you blit all 5 bit planes in one go then you can be preparing the next object's plotting data while the blitter does its job. So it was the old fight of space versus time.

Boooooo
Yeah, and triple buffering is another one of those space versus time conundrums.
alpine9000 is offline  
Old 28 January 2018, 12:01   #71
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 307
Quote:
Originally Posted by alpine9000 View Post
Yeah, and triple buffering is another one of those space versus time conundrums.
Yeah, i do triple buffering already and simplifies things alot.

Actually, i use quad buffering because i hold another copy of background before my bomb sprites are placed. I could save memory there by only restoring behind the bomb because they dont move. Would save around 30k. Using the hardware sprites is going to save another 16k of collision memory. Plenty of efficiencies still to be made.
mcgeezer is offline  
Old 31 January 2018, 22:48   #72
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 307
I haven't had a great deal of time to code over the last few days.

However, I did manage to get some time so I've knocked up the firebomb bonus screen.

Here's the video, not really that much technically to say about it really. Was very straight forward and I opted to use tiles to draw the whole thing.

Middle screen where the text is uses 3 bit planes, other 2 bit planes are used for text colours.

[ Show youtube player ]

P.S. Not sure why the video and audio are out of sync.

Last edited by mcgeezer; 31 January 2018 at 23:03.
mcgeezer is offline  
Old 04 February 2018, 18:15   #73
Steril707
OCS rocks!

 
Join Date: Sep 2016
Location: Munich/Germany
Posts: 387
Can only say the same thing as others had said in this thread: amazing progress.
Steril707 is offline  
Old 06 February 2018, 23:56   #74
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 307
Well, despite trying pretty damn hard I'm going to have to make the initial release of the game requiring 1Mb ram (0.5 Chip + 0.5 Fast).

I simply can't fit all the required assets into ram in one go. If I create a file or track loader I can probably manage it but even then it will be tricky and would incurr load times (mind you, I could do the load time when the little end of round sequence plays).

At the moment with all the samples, music, assets game code in I have about 120Kb of Chip ram remaining. The executable builds (with compressed assets to 222Kb).

The problem is is that I wanted to add a nice title screen so that will bumb things up a bit and use up that 120Kb chip.

I'm disappointed but nothing I can do in the short term.
mcgeezer is offline  
Old 07 February 2018, 13:53   #75
Steril707
OCS rocks!

 
Join Date: Sep 2016
Location: Munich/Germany
Posts: 387
Well, 512k chip+ 512 trapdoor RAM is kind of the basic Amiga configuration, so don't worry. It's even standard on UAE if you choose the Amiga 500 I believe.

It would be different though, if you needed real fast RAM or a faster CPU for the game to run.
Steril707 is offline  
Old 07 February 2018, 14:13   #76
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 307
Quote:
Originally Posted by Steril707 View Post
Well, 512k chip+ 512 trapdoor RAM is kind of the basic Amiga configuration, so don't worry. It's even standard on UAE if you choose the Amiga 500 I believe.

It would be different though, if you needed real fast RAM or a faster CPU for the game to run.
Yeah thanks, the target is for my Amiga A500 with 0.5Mb trap door ram expansion.... so I take it all I have in my Amiga is fake fast right?
mcgeezer is offline  
Old 07 February 2018, 16:27   #77
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 43
Posts: 1,007
Send a message via Yahoo to Samurai_Crow
Quote:
Originally Posted by mcgeezer View Post
Yeah thanks, the target is for my Amiga A500 with 0.5Mb trap door ram expansion.... so I take it all I have in my Amiga is fake fast right?
Yes. The trapdoor memory is called "ranger" memory because it is as slow as Chip RAM.
Samurai_Crow is offline  
Old 07 February 2018, 16:28   #78
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,107
Somewhere I have seen that you used fixed addresses for all your graphics, screens and buffers. Maybe you can implement a small memory management into the game, so you can allocate and deallocate Chip RAM. For example, you won't need all the buffers for BOBs, when displaying the title screen.

Quote:
Originally Posted by mcgeezer View Post
0.5Mb trap door ram expansion.... so I take it all I have in my Amiga is fake fast right?
Depends. When you have a newer, 1MB-capable Agnus, you could also add the trap door as Chip RAM. In any case, all memory will be as slow as Chip RAM.
phx is offline  
Old 07 February 2018, 21:20   #79
mcgeezer
Registered User

 
Join Date: Oct 2017
Location: Sunderland, England
Posts: 307
Quote:
Originally Posted by phx View Post
Somewhere I have seen that you used fixed addresses for all your graphics, screens and buffers. Maybe you can implement a small memory management into the game, so you can allocate and deallocate Chip RAM. For example, you won't need all the buffers for BOBs, when displaying the title screen.
I could try that but it would still be very tight.

Here's my current memory map.

Code:
;
; -= Memory Map =-
;   
; +-----------------------------------------------------------------+
; |$02000-$0ffff > Music Module                   $e000L            |
; |$10000-$1afff > Sprite Masks                   $b000L            |
; |$1b000-$1ffff > Free                           $5000L            |
; |$20000-$2afff > Sprite Assets                  $b000L            |
; |$2b000-$2ffff > Free                           $5000L            |
; |$30000-$37fff > Front Screen Buffer            $8000L            |
; |$38000-$3ffff > Free                           $8000L            |
; |$40000-$48000 > Back Screen Buffer             $8000L            |
; |$48000-$5dfff > SFX Samples                   $16000L            |
; |$5e000-$5efff > Upper panel                    $1000L            |
; |$5f000-$5ffff > Bottom panel                   $1000L            |
; |$60000-$67fff > Post Sprites Screen Buffer     $8000L            |
; |$68000-$6efff > Sprite List structures         $6000L            |
; |$6e000-$6ffff > Hardware Sprites               $2000L            |
; |$70000-$77fff > Pre Sprites Screen Buffer      $8000L            |
; |$78000-$79fff > Tile Collisions                $2000L            |
; |$7a000-$7bfff > Enemy Collisions               $2000L            |
; |$7c000-$7dfff > Bomb Collisions                $2000L            |
; |$7e000-$7e3ff > Copper List                     $400L            |
; |$7e400-$7ff00 > Stack                          $1b00L            |
; |$7fff0-$7ffff > Exception Handler                $10L            |
; +-----------------------------------------------------------------+

; All chip mods are $d400 in size
As you can see it's pretty tight in there.

I keep all of the assets compressed which then unpack to chip ram. I think a good compromise for the game would be full load if the target has a 1/2 meg expansion but if it's a stock Amiga A500 then it'll be track loading the levels.

Each level would load the background scene and music module.

It's an interesting problem, should be a good challenge to solve.
mcgeezer is offline  
Old 07 February 2018, 22:15   #80
Shatterhand
Warhasneverbeensomuchfun

Shatterhand's Avatar
 
Join Date: Jun 2001
Location: Rio de Janeiro / Brazil
Age: 35
Posts: 2,943
Quote:
After that it will be on to the enemies so in between a bit of coding I've been learning a fair bit of trigonometry - amazing what I didn't learn at school.
I always say this. I did have trigonometry at school, failed hard at it.Nowadays I understand it very well and even explains it to other people.

I learned it coding games. Schools could do a whole better job of teaching stuff if they did it in a practical way
Shatterhand 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
Docs on writing a handler TCH Coders. System 9 18 June 2017 03:46
Writing an (Xbox 360) Kinect USB Driver - achievable? lantus360 Coders. General 3 13 December 2016 13:56
Process for writing original game disk image to disk Doc99 New to Emulation or Amiga scene 6 19 May 2016 12:20
Writing AVI BippyM support.WinUAE 16 20 May 2005 23:43
Found -> Champion Driver (was: top view racing game) T_hairy_bootson Looking for a game name ? 3 06 December 2003 19:08

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 06:41.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.09255 seconds with 15 queries