English Amiga Board Double Dragon - Arcade port in C
 Register Amiga FAQ Rules & Help Members List  /  Moderators List Today's Posts Mark Forums Read

 17 September 2020, 05:53 #81 skyzoo73 Registered User   Join Date: Sep 2019 Location: Italy Age: 48 Posts: 194 Update 15th September 2020 "SETTING UP FOR 2 PLAYERS Something I forgot to mention in the last update was that we have set up the game to work for 2 players. These players now live in our gameWorld environment and we can can use the same PlayerState code for each player." http://www.electriccafe.xyz/double-dragon
 17 September 2020, 05:55 #82 skyzoo73 Registered User   Join Date: Sep 2019 Location: Italy Age: 48 Posts: 194 Update 16th September 2020 "JUMPING AND BOUNDARY COLLISION Something I was excited to see working was the code I had previously written for jumping. It works by taking note of the starting Y pos. We then calculate how much positive or negative speed to add to the Y pos each frame: yvector = yvector + gravity; The Y vector is our jump speed in the above code, we add gravity to it each frame to reduce it. This means after a certain point the Y vector will be come negative and this will bring the player back down again. The following code updates the Y pos each frame by add the Y vector it, initially this is positive taking the player up, as it turns negative the Y pos starts to return to it’s original position. ypos+=yvector; When the Y pos returns to the starting position we then change the player state to idle and the jump it finished. Boundary collision is fairly simple, after we have calculated all the movement we do a final check to see if we have gone beyond our set boundaries. I call a function to do this, checking both the left and right side of the screen: if (xpos>277) {xpos=277;} if (xpos<1) {xpos=1;} So if the player had moved to X pos 280 on the right side of the screen, the code moves it back to 277. Doing the check after all the movement is calculated ensures we don’t get any weird jerky movement." http://www.electriccafe.xyz/double-dragon
 17 September 2020, 15:37 #83 skyzoo73 Registered User   Join Date: Sep 2019 Location: Italy Age: 48 Posts: 194 Update 17th September 2020 "BASIC MOVESET & LINKING COMBOS The following clip shows we can now trigger all the standing moves, and we can link punches and kicks together. I.e. We can go from Punch2 to a Roundhouse or from a Kick to an Uppercut. We do this by assign a combo value to each move. So Punch1 is 1, Punch2 is 2, Uppercut is 3, Kick is 2 and Roundhouse is 3. We use a combo timer to keep track of the linking, if the player is still within time they can go from Punch 1 to a stronger move, if the time runs out the combo value is reset to 0 and they start with the basic punch and kick again. In the future I will probably allow finishing moves to be performed on stunned opponents, aswell as part of a combo. But we will see. Watch the Player State at the top to see the moves being linked. Tomorrow we will draw some hit boxes to really show off the moves." http://www.electriccafe.xyz/double-dragon Last edited by skyzoo73; 27 September 2020 at 23:46.
 27 September 2020, 21:57 #84 skyzoo73 Registered User   Join Date: Sep 2019 Location: Italy Age: 48 Posts: 194 UPDATE 26th September 2020 "Quick Catchup Just a quick one to say we’ve making loads of progress on a variety of things which I will detail more closely in future updates. The default moveset is now complete, we added the back elbow and headbutt last night. It works brilliantly, even with one joystick button it all feels good. We are also prepping for how we are going to bring in the graphics, bearing in mind we will be switching the palette between levels. What I have discovered is that with some very careful planning I have been able to retain all the depth of the arcade sprites and most of the background details, just by being economical and artistic with the palette choice. This improves upon the initial mockup at the top of this page. I was never a fan of the woods graphics, and noticed they changed this in the GBA version, so I have done a rework myself providing a far moodier setting over the garish original. In a future update I’ll do some proper sprite and background comparisons. In addition we are setting up hitboxes, animation systems and enemy AI and I’ve completed pretty much all the music." http://www.electriccafe.xyz/double-dragon Last edited by skyzoo73; 27 September 2020 at 23:42.
 03 October 2020, 18:51 #85 skyzoo73 Registered User   Join Date: Sep 2019 Location: Italy Age: 48 Posts: 194 Update 3rd October 2020 "Tilesheets & Tilemaps As is standard with old games a tilesheet and a tilemap are necessary for building the levels. I have been working hard to create a dedicated palette with 10 swappable colours per level. Using this I have been able to create an indexed colour tilesheet. The tiles are 16x16 pixels. To create the tilemap I am using Tiled, a great piece of software by Thorbjørn Lindeijer. A great feature is that the tilesheet can be updated live, so I can have Photoshop open and tweak bits and see it update live in Tiled. Very cool! I have used this to tidy up a few bits that looked a bit off. Tiled can export a .csv tilemap file which basically gives you a bunch of number in rows that correlate to the 16x16 tiles in the tilesheet. We can import this data along with the tilesheet and rebuild it in our code. So you get something like this: Once all the elements come together, the mock up below shows the exact assets we will be drawing to the Amiga screen (best viewed on a CRT!) This mockup uses 32 colours and a 256x240 resolution (same as the arcade)." http://www.electriccafe.xyz/double-dragon
 03 October 2020, 23:28 #86 redblade Zone Friend   Join Date: Mar 2004 Location: Middle Earth Age: 37 Posts: 1,860 Amazing work, what number out of the 32 colours are then 10 changable colours? Are they in the sprites? or are they mixed, 5 sprites, 5 lower 16 colours. Once again, it looks amazing. Will the final game be 256x240 for speed or are you going to try to push for 320x240?
 04 October 2020, 01:31 #87 lmimmfn Registered User   Join Date: May 2018 Location: Ireland Posts: 333 Looks fantastic, keep up the great work!!!
 04 October 2020, 07:23 #88 kriz Junior Member   Join Date: Sep 2001 Location: No(R)Way Age: 39 Posts: 2,967 Damn, tasty !!
 05 October 2020, 04:34 #90 redblade Zone Friend   Join Date: Mar 2004 Location: Middle Earth Age: 37 Posts: 1,860 Thanks for that information. The billy and the enemy sprites look great . 256x240 is going to be great . I can't wait to play it.
 07 November 2020, 02:09 #91 skyzoo73 Registered User   Join Date: Sep 2019 Location: Italy Age: 48 Posts: 194 6th November 2020 AI Part 1 "The AI for this game will be iterated upon in stages. The first thing we need to achieve is for an enemy to first follow a player. As mentioned previously our players and enemies are now belong to our GameWorld in code. This essentially means that the player code and the enemy code can access each other’s variables such as position & health. These 2 variables are important, because the enemy will need to know the player’s X & Y position to be able to move towards them and they will need to access the player’s health to pass damage to them (when they attack). As the game is in pseudo 3D, we will use a Z coordinate for the player (and enemy), this for the most part will be the same as the Y position except when the player jumps, in which case Y will go up and down, while Z will remain the same. The reason we need this is so the enemy does not follow the player’s actual Y position on screen when they jump. The player is simply jumping up and down from a Y position, hence Z can be used. So for the code the first thing we will do is make the enemy check the position and distance of the player, we write this like so: enemy->target_dist_x = distance(enemy->xpos,gameWorld->player1.xpos); enemy->target_dist_z = distance(enemy->zpos,gameWorld->player1.zpos); The enemy holds variables for the target distance for X and Z. We call a function I wrote called “distance” and pass 2 arguments, the enemy’s X position and the player’s X position. This is a very simple function that returns the difference between 2 values. int distance(int a, int b) { int distance; distance = (b-a); return distance; } So now we have distance values for both X and Z we can start to do something with it. Another variable we will use for the enemy will be SIGHT_RANGE, this will be the distance the player will need to be to the enemy before the enemy thinks about doing something, otherwise they will Idle. if (enemy->target_dist_x > -SIGHT_RANGE && enemy->target_dist_x < SIGHT_RANGE) { ChooseMovement(enemy, gameWorld); SwitchEnemyState(PLAYER_STATE_WALK, enemy, gameWorld); } else { SwitchEnemyState(PLAYER_STATE_IDLE, enemy, gameWorld); } As you can see if the player is within range we then call a ChooseMovement function. This is basically the enemy deciding whether to move to the front or back of the player. In the future this will take in many other factors such as other enemies already being in those positions, but for now it is simple. if (enemy->target_dist_x < 0) { PositionFront(enemy, gameWorld); } else { PositionBack(enemy, gameWorld); } So if the X target distance value is negative then they will move to the front of the player. If it is positive then they will move to the back. PositionFront and PositionBack are 2 functions we use to start to control the movement of the enemy. ATTACK_RANGE is a variable we will use to set the distance an enemy should place themselves away from the player to attack. So we do the following for positioning in front of the player (to the right). if (enemy->xpos > gameWorld->player1.xpos+ATTACK_RANGE) { enemy->xvector = enemy->xspd*sign(enemy->target_dist_x); } else if (enemy->xpos < gameWorld->player1.xpos+ATTACK_RANGE-10) { enemy->xvector = enemy->xspd*-sign(enemy->target_dist_x); } Walk(enemy); Here we are saying if the enemy is not yet at in position then set their X vector (the variable we use to move the enemy) to their walk speed in the direction of the player. Else if the enemy is too close (i.e. on top of the player) then move back a bit. At the end we call the Walk function which uses the X vector to move the enemy’s X position like so:" enemy->xpos += enemy->xvector; We do the same for the Z position. This is what it looks like:
 07 November 2020, 21:23 #92 rothers Registered User   Join Date: Apr 2018 Location: UK Posts: 292 Looking really good, it's so cool to see people showing what the Amiga can do when it comes to arcade conversions.
 08 November 2020, 20:54 #93 redblade Zone Friend   Join Date: Mar 2004 Location: Middle Earth Age: 37 Posts: 1,860 Looks great. How are you going to change between the levels? Are they going to walk across like the arcade or will the screen go black and reload again on the next level?
08 November 2020, 21:36   #94
skyzoo73
Registered User

Join Date: Sep 2019
Location: Italy
Age: 48
Posts: 194
Quote:
 Originally Posted by redblade Looks great. How are you going to change between the levels? Are they going to walk across like the arcade or will the screen go black and reload again on the next level?

ElectricCafe should be asked directly, however I continue to report here on EAB directly from its web page http://www.electriccafe.xyz/double-dragon

 12 November 2020, 00:30 #95 skyzoo73 Registered User   Join Date: Sep 2019 Location: Italy Age: 48 Posts: 194 UPDATE 11th November 2020 "THE ENTRANCE OF ABOBO THE GIANT Written by Kazunaka Yamane, this is a minimal and effective composition that perfectly captures the brutal smackdown that awaits you at the end of each level. Here is my version that I hope goes some way to doing it justice on the Amiga." http://static1.squarespace.com/stati...al/v5_boss.mp3
 12 November 2020, 14:04 #96 skyzoo73 Registered User   Join Date: Sep 2019 Location: Italy Age: 48 Posts: 194 12th November 2020 AI PART 2 "It’s worth noting at this point that my approach to AI is inspired by this guide by David Silverman. When I wrote my first beat’em up engine in Gamemaker a few years ago, this was the guide I followed. In C the way it is coded is different but many of the concepts remain the same. So today we are showing off those hit boxes I keep talking about and using them to collide with the player, drain health and eventually end their green rectangular life. First of all we are expanding our ChooseMove function: We have added a check here to see if the Enemy is close enough to the player to think about attacking. We check this on the X and Z axis. If close enough then we run the CheckAttackChance function, this is where the enemy will have some randomising AI that controls how aggressively they attack. Eg. the grunt enemies will not attack as frequently as the big boss enemies. So currently each frame the enemy’s aggressiveness will increase by 1. It then checks to see if the aggressiveness value is higher than a randomly picked number between 0-100. If so it will trigger the enemy’s Punch1 state (incorrectly labelled as PLAYER STATE PUNCH1 but I’ll clean that up later) Eventually I will add more code here to choose from a variety of attacks. So in the SwitchState function we do some one off things like setting the length of the attack and eventually triggering animation and SFX like so: With the state now set to PUNCH1 the code then comes back into the UpdateEnemyState function where it will run the EnemyAttack function each frame until it is finished. EnemyAttackTimer simply reduces the attack_timer value by 1 each frame. We then trigger the hitbox and collision detection some time after the attack has started as we want it to sync with the frame of animation where the arm is extended. We use a hitboxTime argument to control which frame we want this to happen. So if attack_timer is less than say 3 it then triggers the hitbox and collision detection. When the attack_timer is 0 we then turn of the hitbox, reset their aggressiveness and set the enemy’s state back to Idle (so they can start again). All of this will be expanded in the future to allow for enemy combos and other things but for now we can do some simple attacking like this. And what we get may look like a primitive sex game but it provides the basics of our beat’em up engine The next AI update will include hitbox collision and passing variables between player and enemy."
 01 December 2020, 20:39 #97 skyzoo73 Registered User   Join Date: Sep 2019 Location: Italy Age: 48 Posts: 194 1st December 2020 PROGRESS UPDATE "I’ve been meaning to post an update for a few weeks for the AI but haven’t got round to creating a video for it yet, but I will post that soon. What it will show is that the basic main engine is complete. We now have a beat’em up engine that can handle multiple enemies in idling, patrolling and attacking states. They all know about each other and make intelligent choices based on the player’s position. It all works really well so I will look forward to showing that off. I’ve also addressed an issue of responsiveness in that it felt a little sluggish previously, this was because when I am switching between states I am not actually running the code for that state until the next frame. So to solve the issue a state’s code is always run in conjunction with the state change, and this results in super responsive gameplay. We also have great hitbox collision, this is very clear to see when performing a flying kick. So to summerise we have completed the following so far: Player controls and moveset Enemy AI for multiple enemies Hitbox collision Take damage, reduce health and die All music arrangements, many already converted to Mod format SFX prepared at both 22Khz and 11Khz, with the 11Khz results more than acceptable due to EQ tweaks Colour palettes for all levels Tilesets ready for 3 levels All sprites prepared With all this work done so far it allows us to plan how we will use the memory available. See the next update." http://www.electriccafe.xyz/double-dragon
 01 December 2020, 20:41 #98 skyzoo73 Registered User   Join Date: Sep 2019 Location: Italy Age: 48 Posts: 194 1st December 2020 MEMORY MANAGEMENT "As we have previously stated we will be creating this game for the Amiga 500 with 1mb RAM. In my opinion this is the classic Amiga setup and see no point in creating AGA versions for A600/A1200 as no one I knew had one back in the day, but everyone had an Amiga 500 and indeed most had the 1mb upgrade. So the challenge is to create within the limitations. The internal 512Kb RAM will have to contain everything we need at runtime to make the game happen, that is the display, audio and code. This is because the Amiga Blitter, Copper and Paula chips interact directly with this RAM chip (is the way I understand it anyway). So we will use the additional 512Kb for stuff we want to swap in, this can be things like additional spritesheets and audio we don’t need all the time etc. an example would be Willy’s gun sound, we don’t need this until the end of Level 5 so we will make it available just before we need it. This approach frees up the internal RAM somewhat in the hope we can have all the music and graphics from the arcade game without having to sacrifice anything due to RAM limitations. With that said and the work done so far, we can start to do some super rough calculations: Internal 512Kb RAM Music 70Kb (will contain the level, boss and cutscene music in the same file) SFX 70Kb (these will be the core most used sounds) Display 40Kb (the screen is 256 x 240 x 5bitplanes) Code 30Kb This leaves 300Kb currently Expansion 512Kb RAM Background Tileset 50Kb Player Sprite 70Kb Enemy Sprites 200Kb (ish..) Additional GFX such as weapons, fonts 70Kb Additional Audio 50Kb Cutscene GFX 20Kb This will all be loaded per level, so when you complete we will cut to the preloaded cutscene GFX and music and then start dumping the old stuff out and loading the next level’s assets in. Having the game on 2 disks is expected but may not be necessary, we will see on that one If it is, then disk swapping will happen during the cutscene so will not interrupt gameplay. This is all of course based on what we know so far, I expect all of that free memory to be used by one thing or another at some point but it’s all very encouraging." http://www.electriccafe.xyz/double-dragon
16 January 2021, 02:28   #99
agermose
Registered User

Join Date: Nov 2019
Location: Odense / Denmark
Posts: 159
Quote:
 Originally Posted by skyzoo73 1st December 2020 MEMORY MANAGEMENT "As we have previously stated we will be creating this game for the Amiga 500 with 1mb RAM. In my opinion this is the classic Amiga setup and see no point in creating AGA versions for A600/A1200 as no one I knew had one back in the day, but everyone had an Amiga 500 and indeed most had the 1mb upgrade. So the challenge is to create within the limitations. The internal 512Kb RAM will have to contain everything we need at runtime to make the game happen, that is the display, audio and code. This is because the Amiga Blitter, Copper and Paula chips interact directly with this RAM chip (is the way I understand it anyway). So we will use the additional 512Kb for stuff we want to swap in, this can be things like additional spritesheets and audio we don’t need all the time etc. an example would be Willy’s gun sound, we don’t need this until the end of Level 5 so we will make it available just before we need it. This approach frees up the internal RAM somewhat in the hope we can have all the music and graphics from the arcade game without having to sacrifice anything due to RAM limitations. With that said and the work done so far, we can start to do some super rough calculations: Internal 512Kb RAM Music 70Kb (will contain the level, boss and cutscene music in the same file) SFX 70Kb (these will be the core most used sounds) Display 40Kb (the screen is 256 x 240 x 5bitplanes) Code 30Kb This leaves 300Kb currently Expansion 512Kb RAM Background Tileset 50Kb Player Sprite 70Kb Enemy Sprites 200Kb (ish..) Additional GFX such as weapons, fonts 70Kb Additional Audio 50Kb Cutscene GFX 20Kb This will all be loaded per level, so when you complete we will cut to the preloaded cutscene GFX and music and then start dumping the old stuff out and loading the next level’s assets in. Having the game on 2 disks is expected but may not be necessary, we will see on that one If it is, then disk swapping will happen during the cutscene so will not interrupt gameplay. This is all of course based on what we know so far, I expect all of that free memory to be used by one thing or another at some point but it’s all very encouraging." http://www.electriccafe.xyz/double-dragon
Great project. Your mem calculations for the screen seem a bit off. You need an extra 16 pixels horizontally for the scrolling. And unless you want choppy gfx you need at least dual screen buffers. Have you added mem for the blitmasks for the sprites? Assuming they are software sprites.

16 January 2021, 16:19   #100
DamienD
disengaged

Join Date: Aug 2005
Location: London / Sydney
Age: 45
Posts: 20,392
Quote:
 Originally Posted by agermose Great project. Your mem calculations for the screen seem a bit off. You need an extra 16 pixels horizontally for the scrolling. And unless you want choppy gfx you need at least dual screen buffers. Have you added mem for the blitmasks for the sprites? Assuming they are software sprites.
It's not skyzoo73's project; he just posts the news from the external project webpage here in this thread...

It's ElectricCafe's project

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

 Similar Threads Thread Thread Starter Forum Replies Last Post ZEUSDAZ Retrogaming General Discussion 20 16 January 2021 14:29 The Master project.WHDLoad 2 04 June 2006 20:20 fryguy request.Old Rare Games 2 17 November 2005 02:31 Konrad support.Games 3 09 October 2002 00:04

 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 Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home News Main     Amiga scene     Retrogaming General Discussion     Nostalgia & memories Support     New to Emulation or Amiga scene         Member Introductions     support.WinUAE     support.WinFellow     support.OtherUAE     support.FS-UAE         project.AmigaLive     support.Hardware         Hardware mods         Hardware pics     support.Games     support.Demos     support.Apps     support.Amiga Forever     support.Amix     support.AmigaOS     support.Other Requests     request.UAE Wishlist     request.Old Rare Games     request.Demos     request.Apps     request.Modules     request.Music     request.Other     Looking for a game name ?     Games images which need to be WHDified abime.net - Hall Of Light     HOL news     HOL suggestions and feedback     HOL data problems     HOL contributions abime.net - Amiga Magazine Rack     AMR news     AMR suggestions and feedback     AMR data problems     AMR contributions abime.net - Home Projects     project.Amiga Lore     project.EAB     project.IRC     project.Mods Jukebox     project.Wiki abime.net - Hosted Projects     project.aGTW     project.APoV     project.ClassicWB     project.Jambo!     project.Green Amiga Alien GUIDES     project.Maptapper     project.Sprites     project.WinUAE - Kaillera Other Projects     project.Amiga Demo DVD     project.Amiga Game Factory     project.CARE     project.Amiga File Server     project.CD32 Conversion     project.Game Cover Art         GCA.Feedback and Suggestions         GCA.Work in Progress         GCA.Cover Requests         GCA.Usefull Programs         GCA.Helpdesk     project.KGLoad     project.MAGE     project.Missing Full Shareware Games     project.SPS (was CAPS)     project.TOSEC (amiga only)     project.WHDLoad         project.Killergorilla's WHD packs Misc     Amiga websites reviews     MarketPlace         Swapshop     Kinky Amiga Stuff     Collections     EAB's competition Coders     Coders. General         Coders. Releases         Coders. Tutorials     Coders. Asm / Hardware     Coders. System         Coders. Scripting         Coders. Nextgen     Coders. Language         Coders. C/C++         Coders. AMOS         Coders. Blitz Basic     Coders. Contest         Coders. Entries Creation     Graphics         Graphics. Work In Progress         Graphics. Finished Work         Graphics. Tutorials     Music         Music. Work In Progress         Music. Finished Work         Music. Tutorials

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

 -- EAB3 skin ---- EAB2 skin ---- Mobile skin Archive - Top