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

TheMole

Members
 View Profile  See their activity

  • Content Count

    855

  • Joined

  • Last visited

Posts posted by TheMole

  1. Posted

    So are you planning on creating 2 versions, one for the stock 9918 and one for the F18A?

     

    I plan to make one version that detects and supports both chips. I was thinking about doing something for the v99x3 as well, but I don't know how feasible it is.

  3. Posted

    Rasmus, do you still support a downloadable version of js99er? I'd like to add some debugging tools that would benefit me personally (and anyone else using js99er to do GCC development in). Basically, I'd like to be able to read in a linker map file (such as the one attached) and be able to use the symbols in that file to watch memory, set the breakpoint, etc...

     

     

    linker_map.txt

  4. Posted

    I have a question for you Mole, do you plan to make a ready-to-download image for the Uber Cart?

     

    Well... I don't want to put the cart before the horse (HAH! :D), but I'm toying with the idea of doing a real cartridge release in professional/commercial packaging if I can garner enough interest in it to offset the cost of doing a run of manuals, stickers, boxes, ... currently I think somewhere north of 50 preorders should be enough.

     

    I'll definitely also release a ready-to-burn image, but I might wait until I've given preorders a chance. And as Ksarul pointed out, I'm looking to target the red 512k boards (which will be the minimum requirement), but it will work with the Ubergrom as well.

    • Like 1

  5. Posted

    Thanks for the kind words everyone. Here's another update video, this time with ECM3 sprites and f18a graphics for the second level as well. Some small bugs here and there in my export tools (red edge on blue balls in first level, glitchy fire sprite in second level), but the engine is humming along nicely and getting more flexible by the day.

     

     

    Oh, remind me to do something about those moonwalking scorpions... :D

    • Like 9

  9. Posted

    Ugh... I gotta stop posting late at night when I've been looking for a bug for too long. Sorry for pointing fingers, turns out that there was a bug in my (long standing) loading code, which loaded the wrong values in my replacement table. That piece of code had been working great for a long time, so I never bothered checking it.

     

    Thanks for the quick replies regardless guys, much appreciated!

  10. Posted · Edited by TheMole

    I'm seeing a strange issue with non-positional attributes in js99er (maybe issue is the wrong word, I might not be understanding how it's supposed to work). Haven't been able to test on real hardware yet, but I'm hoping you guys can help regardless.

     

    So, I've got a setup with two tile layers, with TL2 being the foreground, and TL1 a parallax scrolling background. Hence, a lot of tiles in TL2 are either fully transparent or have transparent pixels. I'm using the following register values:

    VDP_SET_REGISTER( 4, 0x04);	// Pattern table at 4 * 0x800 (0x2000 - 0x3800)
VDP_SET_REGISTER( 2, 0x04);	// Nametable, 0x04 * 0400 (0x1000 - 0x1400 & 0x1800 - 0x2000)
VDP_SET_REGISTER( 3, 0x4c);	// Attribute table, 0x4c * 0x40 (0x1300 - 0x1400)
VDP_SET_REGISTER(10, 0x00);	// Second name table at 0 * 0x400 -> 0x0000 - 0x0300 & 0x0400 - 0x0700
VDP_SET_REGISTER(11, 0x0c);	// Second attribute table at 12 * 64 = 0x0c * 0x40 -> 0x0300 - 0x0400 & 0x0700 - 0x0800
VDP_SET_REGISTER(25, 0x00);	// Reset scroll registers TL2: Horizontal
VDP_SET_REGISTER(26, 0x00);	// Vertical
VDP_SET_REGISTER(27, 0x00);	// Reset scroll registers TL1: Horizontal
VDP_SET_REGISTER(28, 0x00);	// Vertical
VDP_SET_REGISTER(29, 0x20);	// Set 2 horizontal pages for TL1
VDP_SET_REGISTER(49, 0xb0);	// 0xb0 = TL2 enable | ECM3 for tiles
VDP_SET_REGISTER(50, 0x01);	// Per tile attributes: TL2 adheres to sprite/tile priorities

    So, attributes are per pattern and not per nametable entry. I have copies of the attribute table in both pages for TL2 and a copy for TL1. I'm unsure whether it is necessary to have all three copies, but I figured better safe than sorry...

     

    This seems to work just perfectly, but when I 'wipe' stuff out by dynamically changing the nametable entries for the changing location of TL2 (in either page) by writing zeroes to it (pattern zero is all zeroes and has the transparency flag set in it's attributes), it neatly writes the pattern as expected, but it forgets about the transparency.

     

    At the end of this video, you can see an example of this in action (around the 40th second or so, Alex punches two blue blocks and they get replace by black squares while it should be transparent, like the rest of instances of that pattern all around it).

     

    I only see two possibilities at this moment: either I'm completely misunderstanding how per-name attributes work (entirely possible and perhaps even way too likely), or there's a bug in js99er (but that would be the first I've seen in the F18A implementation)?

    • Like 3

  11. Posted

    Still a lot of work on this one, but I'm too excited not to share a sneak preview:

     

    F18A features used: ECM3 tiles, two independently smooth scrolling layers; but still 'classic' non-ECM sprites. Also, a small annoying bug that I'm not understanding at the end there...

    • Like 10

  12. Posted

    If the group is going to pick up on the "build our own joystick" idea, I have a request: when building new joysticks, we should agree on a (standard) way to add more buttons for single player games. I would very much recommend to wire it so that the "player one" joystick has access to at least two fire buttons. For platform games, this is almost an absolute must, since it is very, very hard to be accurate when you have to push the stick up to jump.

     

    I would very much like to support a two button joystick in Alex Kidd. I had planned on simply reading out the P1 and P2 fire buttons for punching and jumping respectively, but if someone has a better idea, I'm happy to support that instead.

    • Like 1

  13. Posted · Edited by TheMole

    I have a question for you Mole. Since you are planning on making a cartridge version of this game, I was curious, are you planning on using the Uber Cart? I was wondering because if you are planning on writing this in switchable 8K blocks, it occurred to me that you could use and setup a GRAM area to the store game data and carry it over for retrieval upon loading the next block. Also, you could give the user the ability to save the data in this area to disk for later retrieval... so they could save a game in progress and 'start where they left off' another day, or possibly even keep a permanent high scores list. Just pondering...

     

    I'm targeting a standard 512k image, for price reasons (I want to make sure it stays affordable, and leave some room to splurge on packaging, manual, labels, ...). I have thought about saving your status in between levels though, but I'm not sure if I want to add it. Typically, these types of games have an average play-through time of 30-60 minutes once you know how to play it (there are 15 minute speed-runs of the original Alex Kidd on youtube...). A lot of the replay value comes from the fact that you'll need to start over again a number of times before you're good enough to get through it in one sitting.

     

    Having said that, times have changed, and modern gamers expect save functionality. If I do add it (undecided) it will be via a password system though (again, for that old skool type of feel). The cool thing about that approach is that all save data is encoded in the password, meaning you don't have to actually save anything on disk or NVRAM/battery backed RAM.

     

    Also, note that this game will require the 32k expansion. There's just no way I can fit the dynamic levels and graphics data in VRAM, AND keep the game running at an enjoyable speed.

    • Like 4

  14. Posted

    Ok, we're finally back where we were before the move from disk to cartridge and we have enemies walking around our levels! This took a lot longer than I expected due to unexpected alignment issues and me stupidly forgetting that my tools needed to convert data to big endian format for the TI... (crazy that I hadn't ran into this before, but apparently all my previous tools only generated bytes and never words or double words... go figure...). Also, I now have more than 64k of data being loaded, which meant I had to revamp the way I let gcc pass on the location of data in the cartridge image: ld exports pointers to the data, which meant I was limited to 16bit. I had to write a script that pre-links the resource files, so I know where they will end up in the image and generates an include file from the linker's map file... cumbersome, but I think I found a cross-platform way of doing this in shell script. Added bonus: I no longer need to manually add external resources to my code, every file that I add to the resources folder will automatically get linked into the image :).

     

    The first level in the clip is a relatively faithful copy of a level in the original game, including the enemy positions. For the second level, I just slapped some enemies where it looked ok to test the routines. Will need to do some serious tweaking to make the levels feel fair... :).

     

     

    Next up (and before I release a demo cartridge image):

    • Clean up collision detection with enemies a bit (I'm not going for pixel perfect, but currently it's way off sometimes)
    • Add a third level
    • Add some different looking enemies for the other 2nd and 3rd levels
    • Add an F18A rendering path

     

     

    • Like 8

  18. Posted · Edited by TheMole

    Damn, those animations are beautiful! You're really raising the bar with this one.

     

    Regarding the horizontal scrolling: putting the panel at the bottom would impact gameplay more than just making the map narrower. One of the reasons it doesn't look very nice right now might be because you're forced to scroll relatively small distances in 8 pixel increments. It might look better if you could find a way to scroll less often, but 'further', if that makes sense...

     

    The example below uses this technique (but the other way around: it does smooth horizontal pixel scrolling, and vertical character based scrolling). Every time the character lands after a jump, the engine rapidly scrolls to center the image around the player. If you don't know which trick he's using you'd be hard pressed to notice that it's not using smooth scrolling techniques. In your case, you might consider splitting your map into two halves and scroll whenever the player ball lands in another half from where it started, each time scrolling as far left or right as you can. To say it with a meme: you wouldn't scroll very often, but when you do scroll, you scroll 64 pixels at once (over 8 frames, for instance).

     

     

    By the way, up until your Bouncy videos, these were some of the most impressive scrolling graphics I'd seen on the 9918a. Some very smart graphics design going on here.

    • Like 2

  20. Posted

    Yes, but I want an SD reading cartridge (I don't mind the CF card for the CF7+), to test and run new cartridge games I plan on writing :). Also, it'd serve as the multicard to end all multicards: want a games compilation? Throw some games on the SD card. Want an educational software compilation? Ditto... Without the need to keep buying carts or to burn EPROMs.

     

    Something like the Mega Everdrive: http://shop.krikzz.com/Mega-EverDrive-v2-MEGAV2.htm

  22. Posted

    Isn't NV SRAM uber expensive at those sizes though? I was looking for a 512kB size chip on mouser and they're around $100!

     

    Does the atmega on the ubergrom board have access to the 512k ROM? If so, it should be feasible to add something like this to the atmega's SPI interface and replace the ROM chip with a non-NV (making it a non-non-volatile? :)) SRAM chip. (Even if this isn't the case, you can route the data through the host system, I guess). But that's way beyond my skill level :).

     

    Either way, I'm ordering my ubergrom cart today or tomorrow and will purchase an appropriate EPROM burner as well for testing Alex Kidd on real iron.

  23. Posted

    Thanks. There may come a few minor changes to mineSweeper, and then it can be included on the mega-cart-compilations. Later, there may be a special multi-cart-compilation.

     

    :)

     

    Cool, although I personally am not a big fan of the mega compilation cart concept (reminds me of those cheap pirate gameboy/NES 40-in-1 cartridges). I like browsing a collection of individual cartridges :).

     

    Having said that, I know that's probably just me and other people will prefer the many-in-one approach. I can always burn an 8k cart myself :) (but if you ever do decide to put out a cart, you've got my money!).

    • Like 1
AtariAge
Forums
Store
General
Follow AtariAge

Copyright ©1998-2021 AtariAge

×
×
  • Create New...