Jump to content
Have You Played Atari Today?
2600|5200|7800|Lynx|Jaguar|Forums|Store  

splendidnut

+AtariAge Subscriber
 View Profile  See their activity

  • Content Count

    500

  • Joined

  • Last visited

Posts posted by splendidnut

  1. Posted

    I don't have a working build at the moment.  Lol.

     

    You can try playing around with the colors using the version from this post:

     

    Colors will look weird on PAL60 since it's using the NTSC-based color selections.  But it should work.

     

    I played around with it real quick in Stella.  If you set the colors to 35, E7, DC, 4C, that should provide a decent starting point.

    • Like 1

  2. Posted

    Sorry, no actual updates on this.  I've been playing around with different bank-switching schemes, but that's about it.  I've also thought about the PAL color issue.  I think the green background is pulling the orange cliff more towards being a yellow color.  So, I'll probably play around with switching the colors to just browns and blues for PAL.

     

    I will admit that I did get distracted going down another rabbit hole:

     

    But that might actually help pull this project along, since they'll both need the same or very similar game logic.

     

    • Like 2

  4. Posted

    Ultimately, my goal is to make this into a full game, with a sub-goal of trying to do this in parallel with the 2600 version I'm working on.  So far, this one (7800) version has stolen my attention.  I have a few other projects in the works that I'll be juggling around (to keep things interesting).  So, no promises, but we'll see where this goes.

     

    Anyways, here's an update with some of the movement code stolen from my 2600 version.  It's not perfect nor complete, but it's fun to play around with.  I've fixed Bongo's colors using the darker shades in the $3x hue range, as that provides the best contrast/color appearance both in an emulator and on a CRT.  Let me know what you think.

     

    Enjoy.

     

    congo-(20210313).a78

     

    image.thumb.png.ff426c1229ecc3c9666ac565a578b2e9.png

    • Like 11

  5. Posted

    On 3/6/2021 at 8:15 PM, x=usr(1536) said:

    Oh, wow.  That is some killer work.  Congo Bongo is one of my all-time favourites, and it's fantastic to see a screenshot that is so close to the arcade game's graphics.  None of the home versions have really done it justice in that regard, IMHO.

     

    Hmmm...  A graphics engine that works for Congo Bongo should also be able to support the other Sega isometric games (Zaxxon, Super Zaxxon, and Future Spy, though the less said about Future Spy the better).  Just saying :-D

     

    Thanks.  Congo Bongo is one my favorites.  I was a bit surprised with how well the background graphics scaled down to 160 horizontal pixels.  My backup plan was to try and figure out how to wrangle one of the 320 pixel modes, but after seeing the results of this, I decided it was completely unnecessary.

     

    As for reuse in games like Zaxxon, it's a mixed bag.  Currently, this engine doesn't support any form of scrolling.  But I'm trying to keep the display list generator code as a separate module, so it could be shared/re-used in other projects.  Scrolling on the 7800 is something I'm interested in doing, but I wanted to get a basic single screen engine going first.

     

    For this, I might not add scrolling due to the amount of tiles the first level uses (90-95% of a graphics 'bank' is used for the character-set tiles).

     

    On 3/6/2021 at 11:51 PM, Synthpopalooza said:

    Needs POKEY music lol.

    Maybe, at some point when this is more in a "game" demo state.  :)

     

    On 3/6/2021 at 11:57 PM, Synthpopalooza said:

    Also:  160B is fraught with trouble ... it eats up MARIA's DMA processing time.   What you have in 160A looks really good.  160B is fine for sprites, but I wouldn't necessarily use it for play field characters in this instance.

    Indeed.  That's my current goal, keeping the background 160A.  I'm definitely happy with how the background turned out.

     

    As for sprites, I have a feeling the most will end up 160B.  But I'm going to try and keep some at 160A (the monkeys).  We'll see how things go.

     

    On 3/6/2021 at 10:09 PM, SearsRoebuck said:

    I think someone else did a demo of this game before - was that someone else? I dont think it had any movement though

    I've seen a few mockups floating around by @Defender_2600, which inspired me to look into this on the 7800.

     

     

    • Like 1

  13. Posted

    My advice to @bogax

     

    It really sounds to me like you should just jump over the cliff and fully use assembly language.  Especially since you are asking for an IF CARRY construct.

  15. Posted

    I have no horse in this race.  I'm just going along with the idea that some users are asking for a different abstraction to access extra "RAM".  Yes, at the end of the day, DPC+ ram access mainly works best/fastest when treated like a queue/stack.  And that's probably the best abstraction to use for accessing it.  But, it's always nice to have other abstractions available too.  The whole point of using any language other than Assembly language is for the abstractions they provide.  :)

     

    Addendum:

     

    I'm mainly here, because I enjoy these kinds of discussions.

  16. Posted

    3 minutes ago, RevEng said:

    uses one byte for regular variable types

    So this DPC+ thing would be "somewhat" reasonable then? 

     

    You could require the user to prefix the DPC+ variable access with "DPC->" or something similar.

  18. Posted

    Actually, you can take advantage of the same var being read/modified/written to.  So it could be done like this: 

    LDX		#memIndex
STX		DF0LOW
LDA		DF0DATA
clc
adc #3
STA		DFOPUSH

    Granted, for more complicated expressions, it would have to be as you wrote.

     

    5 minutes ago, RevEng said:

    In my mind the question is, should we really abstract away all of those extra cycles and rom?

    Always a good question to ask.  The language is called Basic.  All depends on how "basic" you want to make the language for the users.  :)

     

  20. Posted

    For DPC+, if you limited it to 256 extra vars (page aligned), then for 8-bit vars, the assembly becomes: 

    ;-- setup to read extra variables (only need to do once after end of kernel)

LDA		#extraVarPage 		;-- which 256-byte page to use in DPC+ memory
STA		DF0HI

;---- then for writing a variable:  (value to write in Accumlator)

LDX		#varIndex
STX		DF0LOW
STA		DFOWRITE

;--- OR for reading to a variable  (value read into Accumlator)

LDX		#varIndex
STX		DF0LOW
LDA		DF0DATA

     

    EDIT:  mixed my reads/writes.... ugh :)

     

  21. Posted

    Currently, the easiest way to access/use DPC+ Memory is using a Stack like system (that's just how it's designed)... but it can also be accessed like RAM.  I kinda do this in ChaoticGrill.  It just requires that the Data Fetcher be set before every memory access.

     

    DPC+ Memory access could easily be made easier without the need for complicated ARM programming.   Essentially batariBasic would just need to be modified to "hide" that the memory is not as easily accessible as regular zeropage memory.  Same with SuperChip RAM, CBS+ RAM, E7 RAM... etc.

     

    A new bank-switching scheme COULD (or a new varient of DPC+) be developed that gave a "window" into extra RAM, BUT that would require one of the SD Cart developers to implement it.   OR support could be added to batariBasic to support one of the other bankswitching schemes... it just takes time/willingness of someone to do it.

     

    Granted... I have limited knowledge of batariBasic, but I believe these things are possible.  :)

     

     

  23. Posted

    Hey all,

     

    Here is an early attempt at a graphics engine for Congo Bongo.  I've worked on this mainly over this past week.  This morning I finally added the ability to have a movable sprite (Bongo himself), so I figured it would be good time to show off.

     

    For the engine itself, currently it's using the 160A graphics mode.  The cliff-side is using Indirect (Charactor) Mode.  The water, the trees, the bridge, and the skull are applied as "decal" sprites over top of that.  And then Bongo is added at the end.

     

    To generate the graphics, I'm using an artwork processing tool that I've developed.  The tool let's me easily convert image files I've cut/copy/pasted from an arcade screenshot.  It currently generates a tileset/tilemap usable with this style engine.  So far, it only generates 160A graphics, but I'd like to eventually get it working for ALL the graphics modes.  160B is next on the table... which is needed to improve the appearance of Bongo.

     

    The background is static (no animated water yet), but Bongo is movable with the joystick (NOTE: it's just quick and dirty movement code).

     

    Enjoy.

     

    congo.a78

     

    Edit:  Screenshot for those who asked:

     

    image.thumb.png.75c742279b96b7daa439e1ae6dc4e52b.png

    • Like 21

  25. Posted

    I'm open to any suggestions for the colors... especially for the PAL-side of things, since I only have the Stella emulator palette to check those against.

    • Like 2
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...