Jump to content

Recommended Posts

I see the WIP has paddle, joystick, and joypad support.  Any chance on driving controller support too (asks the guy that has no concept of what kind of implementation details that involves on this platform)?

 

Why do I ask?

 

I ordered the Super Circus AtariAge cart a couple weeks ago and while I'm awaiting its arrival I grabbed one of the old WIPs to look at and I noticed that at least that particular version shows driving controller support!  Not sure if it made it into the final release as the purchase page just shows joystick and paddle.  I don't know if there's anyone else like me, but I've been through a lot of paddle controllers, just can't keep them running smooth whereas I've still got my original driving controllers and they run perfect all these years (decades, sigh) later!

  • Like 2
Link to comment
Share on other sites

6 hours ago, nadir said:

I see the WIP has paddle, joystick, and joypad support.  Any chance on driving controller support too (asks the guy that has no concept of what kind of implementation details that involves on this platform)?

 

Why do I ask?

 

I ordered the Super Circus AtariAge cart a couple weeks ago and while I'm awaiting its arrival I grabbed one of the old WIPs to look at and I noticed that at least that particular version shows driving controller support!  Not sure if it made it into the final release as the purchase page just shows joystick and paddle.  I don't know if there's anyone else like me, but I've been through a lot of paddle controllers, just can't keep them running smooth whereas I've still got my original driving controllers and they run perfect all these years (decades, sigh) later!

Hi! I believe some additional controller support is coming to 7800basic soon so if that includes support for things such as this would be happy to include.

 

Will be getting back to this soon now that Millie and Molly is complete.

 

 

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

  • 1 month later...

Hey everyone,

 

Been working again on Arkanoid the past couple of weeks after finishing Millie and Molly.  I restarted the game from scratch taking the learnings from M&M and apply those back into this project especially around using tiles for the background (replacing very large sprite strips).  Everything has been totally reviewed and updated as I go.

 

Just about everything is in and working (excluding the ball/enemies).  All levels are fully integrated and playable with the flashing brick intro added. The Doh level has been totally re-worked and fully animated now using tiles (no longer any slowdown due to sprites) and the death fully completed.  Finishing off the intro/outro animations ATM and will then be ready to look at the enemies then re-adding the ball.

 

The sprite changes along with a change in 7800basic has given me a lot more room for adding more graphics to the game so we will have no issues adding everything as needed.  Only rendering time will cause me grief going forward here so hoping for 1-2 enemies and up to 3 balls on-screen but we'll see. All those are 160B so going to be interesting.

 

A little teaser of the current state

 

 

 

  • Like 21
Link to comment
Share on other sites

Sometimes a project benefits from a rewrite like this. So tiles take less MARIA time than sprites covering the same area? Interesting. 

 

I've been looking forward to this title for quite some time now - even moreso now that I have a 7800 in my own house (the other belongs to my girlfriend).  :)

  • Like 2
Link to comment
Share on other sites

2 hours ago, Karl G said:

Sometimes a project benefits from a rewrite like this. So tiles take less MARIA time than sprites covering the same area? Interesting. 

Not really. Matt's talking about sprite-based tiles, not tiles-proper. (i.e character-tiles.) The previous design had sprite-tiles on top of extra-wide sprites. This time around, it's just sprite-tiles, and when a brick is removed it's replaced with a background tile, rather than just disappearing and revealing the wide background sprite.

 

 

sprite-based tiles are worse for DMA than a string of characters/tiles, if the sprites are the same width as the characters. But if you use sprite-based tiles that are wider than characters can be, you start to win DMA time. If you need a colorful screen, with different palettes all over the place, then sprite-based tiles become a clear winner over regular character tiles.

  • Like 4
Link to comment
Share on other sites

2 hours ago, Karl G said:

Sometimes a project benefits from a rewrite like this. So tiles take less MARIA time than sprites covering the same area? Interesting. 

 

I've been looking forward to this title for quite some time now - even moreso now that I have a 7800 in my own house (the other belongs to my girlfriend).  :)

Hi Karl, I'm using the process created by RevEng and outlined here: 

 

It would have some strengths and weaknesses depending on what type of game you are coding.  Mike initially suggested it for the bricks in Arkanoid (we still used sprites for the rest including 128pixel strips for the backgrounds).  I took that for Millie and Molly and drew the entire background (12x24 tiles) using this process (it requires some looping to draw tiles that big in 8 zone).

 

Now I'm back to this I thought it might be interesting to see if it could work for Arkanoid.  The main change is replacing these strips with tiles (12x8 - which has saved a huge amount of gfx space) but it also requires management of the backgrounds (like M&M).  When a brick is removed I need to lookup the expected background tile and change it (changing memory pointers not images) - it also allows things such as the brick flash animations for the grey/gold bricks. 

 

I would suggest for map or flick screen games this process would be perfect. Some limitations include no double-buffer, mixing 160A and 160B in a specific tile is a no-no and images generally should exist in the same gfx block although Mike has added an additional method to rectify this since (I haven't used it yet). The Doh level is a perfect example of mixing 160A/160B and requires using strips of images allocated to specific gfx blocks to render the mouth and drain animations - fun fun ?

 

Also thanks for the kinds words everyone.  Really hoping to get this finished in the back-half of the year.

  • Like 5
Link to comment
Share on other sites

  • 2 weeks later...

Work continues on!

 

Have made some great progress not so much adding stuff to the game but getting a few things cleaned up, optimised and running nicely.  Thanks to the great work by @RevEng we have added support for Paddles, Driving Wheels, Amiga and ST Mice as well as consolidating the Joystick selection.  We have also moved all the controller functionality into the left port (previously in the old version joystick left, paddles right) allowing the future use of savekey/atarivox for storage. Mike has done some serious work here in 7800basic to implement this stuff very efficiently, flexible in it's configuration and ease of use - programmers rejoice!!   

 

The front menu selector has been removed so you now use the Select key to set your controller and the left difficulty switch to choose your difficulty (novice or arcade). I've programmed the top enemy gates to open/close ready for enemies to be added and cleaned up the border images and warp animations. Mike also found my brick animation code was not very efficient so this is now updated a few rows every frame.  I also adjusted the intro and outro to give a bit more reading time and finalised some further animation -  just need to add the little ship and vaus animations here to fully complete them.  The Doh level is now complete (excluding ball!) bullets flying and fully animated with flashing and drain animations done all without the previous slowdown.

 

The other big change today was the discovery of more available colors due to the changes in how we lay the screen out - we were able to remove quite a few blacks in the palette as we no longer overlay bricks over the background (the old version).  This has led to a number of objects (ball, vaus bullet and explosion, level warp images) being reduced from 160B to 160A which should be a great help going forward.  I was also able to add the vaus tip flash back in after having to remove it long ago.

 

Next up - still tossing up whether to add the balls or enemies (procrastinating this one I think ?).

 

 

  • Like 14
  • Thanks 2
Link to comment
Share on other sites

  • 3 weeks later...
On 7/11/2020 at 8:03 AM, mksmith said:

Next up - still tossing up whether to add the balls or enemies (procrastinating this one I think ?).

 

So, which did you choose?  :)  Balls makes it playable, but IIRC enemies would have been something new?

Edited by nadir
  • Like 1
Link to comment
Share on other sites

5 hours ago, nadir said:

 

Balls makes it playable, but IIRC enemies would have been something new?

 

Hmmm, strange. My girlfriend played it today for nearly an hour and it worked. ?

Or have i misunderstood something here? ?

New balls please! :P

 

 

  • Haha 1
Link to comment
Share on other sites

Sorry everyone been wanting to post an update but we have been working through a few development scenarios across various areas of the program. 

 

Saying that we have made some good progress adding the balls back in and Mike has been working though the various controller options. We are pretty much back to where the old version was but with optimized ball movement, speed changes and better controller options. We also have added more animations to the intro/outro (TBC) and fully completed the Doh level with much better Doh animation, bullet firing/movement and no slowdown.

 

We've reduced the size of the vaus to better fit within it's surrounds, found more palette colors and improved many areas of the code.  The ball collision could still do with some additional work but 95% of it is working great.

 

Just want to thank the team publicly as at times I've not been happy with my progress. The ball movement/collision really gets me frustrated at times but they continue to lift me up when I get down on myself. It a fine balance between expectations and reality of available processor/render time and finding a balance that works well across the various controllers.

 

Anyway we'll keep plugging away with the enemies next in line. I've already added the top gate open/close animation.

 

 

  • Like 8
Link to comment
Share on other sites

7 hours ago, mksmith said:

The ball movement/collision really gets me frustrated at times

What method do you use?

When I did my pseudo clone I moved all balls by steps equal or lower than one pixel, many times per frame, checking if they cross over brick limits.

With this there is no problem with the collisions (even if you hit more than one brick in the same frame), but the problem is that a higher speeds (and with more active balls) the processing cost is also higher.

So I don't know if this method will work well with the 7800.

Well.. probably there are ways to optimize this, like doing the fine steps only if we are moving through a zone with bricks on it.. but I never explored this solution.

 

 

  • Like 1
Link to comment
Share on other sites

Just now, NRV said:

What method do you use?

When I did my pseudo clone I moved all balls by steps equal or lower than one pixel, many times per frame, checking if they cross over brick limits.

With this there is no problem with the collisions (even if you hit more than one brick in the same frame), but the problem is that a higher speeds (and with more active balls) the processing cost is also higher.

So I don't know if this method will work well with the 7800.

Well.. probably there are ways to optimize this, like doing the fine steps only if we are moving through a zone with bricks on it.. but I never explored this solution.

 
 
 

Hi, yeah pretty much using this type of process. I don't believe you can do anything really advanced calculation wise ie. intersections etc.  I have optimised it by using lookup and velocity tables to reduce the amount of loops required especially for when 3 balls are in play.  Moving cells is the biggest hit for sure as you need to always do an initial determination and then lookup the cell so it makes it tough to get it absolutely perfect for every collision with the available processing/render time.  I have seen some videos recently and ours is (clearly) visually and movement wise well above anything on comparable machines from the day.  I just need to be not so 'perfect' as it does play well overall. Will keep working on it though!

  • Like 2
Link to comment
Share on other sites

  • 4 weeks later...

Just played it on JS7800, and you just may have made the best 8-Bit home port of Arkanoid. Maybe you could port more Taito arcade titles such as Raimais (You may have to include the cutscenes from the Japanese version), Darius, Legend of Kage, Bubble Bobble, Space Dungeon, or Exzisus?

  • Like 3
Link to comment
Share on other sites

@SlidellMan Thanks! We are working hard to make it as good as it can be!

 

The new version we are working on is coming along nicely and is playing even better than the one that is currently available on JS7800. I have recently started working on the enemies which I will provide an update about soon.

 

I would love to do some sort of shooter or another platformer eventually so who knows - those might be an option!

  • Like 6
  • Thanks 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...