Jump to content

RevEng

Members
  • Content Count

    6,846
  • Joined

  • Last visited

  • Days Won

    10

Posts posted by RevEng


  1. 6 hours ago, PacManPlus said:

    I did the '7800 heat' utility again, and there doesn't seem to be any 'problem' or 'out of control' areas...

    7800 heat is good for identifying frequently called small bits of code, but is less useful if the problem is larger chunks of code that aren't as frequently called. (i.e. 10 cycles of instructions looped 10 times will look "hotter" than 100 cycles of instructions called just once, even though the actual cycle cost is the same for both)

     

    Some alternative profiling advice... If you haven't already, I'd see what's eating most of your time by commenting out all BACKGRND register hits, and then before each routine you want to profile, change the BACKGRND color to something unique, and on exit from that routine set BACKGRND back to black. When you play the game, the screen will be a realtime-graph of what the cpu hogs are, relative to each other *and* relative to the overall frame time.

     

    The one weakness of this technique is that it can't identify routines that run during non-visible/vblank time. But since we usually reserve non-visible time for DL updating code, that's not often a problem.

     

    Generally I do the above technique at least once during development, to see how close I am to blowing past the frame timing. For Salvo, it was a useful technique to balance what was happening on even and odd frames. (expensive stuff like collision checks and enemy AI were set to run on different frames, to keep the rest of the action humming at 60Hz)

     

    • Like 6

  2. @-^CrossBow^- I haven't run across a situation where I needed run-and-gun, or even felt compelled to run and gun, and I've been through a fair bit of the game with play testing. That said, if you can point to a video, map, or whatever, I'm totally open to reconsidering that opinion. If run-and-gun is truly required, then we would remove single-proline as an option. If it's a nice-to-have, the alternate control schemes that support it are there. (twin-proline, for one)

     

    @Karl G fair point about not knowing until you try.

     

    Having revisited the keypad layout, based on both of your feedback, I think I might be able to pull-off both quick-item-use and run-and-gun. I was initially worried about both schemes forcing button-soup, where you'd need to memorize the locations of 12 buttons (or play with an overlay and glance down a lot) but this doesn't seem too bad...

    1=use-medkit    2=shoot-up     3=use-bomb
    4=shoot-left    5=???          6=shoot-right  
    7=use-magnet    8=shoot-down   9=use-emp
    *=change-weapon 0=change-item  #=use-item

    The run-and-gun is in an expected cross pattern, with the quick-use items at the diagonals of the cross. Seems workable.

     

    • Like 4

  3. Ok, I'm currently starting to implement the alternate control schemes, and I'm looking for some input from folks who would like to use 2600 keyboard controllers with this game. (recall that I said single-proline action would work well, so this is only for those of you that want to use the keyboard controller)

     

    It seems to me that implementing run-and-gun buttons (shoot-up, shoot-left, shoot-right, and shoot-down) on the keyboard controllers isn't going to work well ergonomically. Picture yourself with a joystick in one hand to move the character, and another on the keyboard controller trying to shoot in different directions. Doesn't seem great, unless you duct-tape your devices down to a table. So for the keyboard scheme I'm inclined to go with the standard change-weapon, change-item, use-item, in addition to fast-use buttons that Crossbow suggested earlier. (e.g. use-medkit, use-bomb, etc.)

     

    Does that work for you guys? Is there anyone looking to run-and-gun with the keyboard, despite the seeming impracticality? I'd rather not implement options for the keyboard scheme, because extra-but-unusable flexibility isn't really a UI win.

    • Like 1

  4. KG BASIC could be...

    • Keyboard Game BASIC
    • Keyboard Graphical BASIC
    • Keyboard Generated BASIC
    • KGBASIC Game BASIC (recursive)

    Just a note that KG BASIC would no doubt be shortened by some users as "KGB". That could be funny or unfortunate, depending on your disposition.

     

    Some other ideas...

    • BASIC78
    • 780 BASIC
    • 78 Console BASIC
    • GOTO 7800
    • Thanks 1

  5. 20 minutes ago, PacManPlus said:

    @RevEng Hoy Crap!  That sounds identical to the arcade!  What chip was that done with?

    Pretty sure it's just a high level simulation of the Williams sound code.

     

    Defender, Robotron, and Joust all use the same sound hardware, which is pretty much just a 6800 CPU connected to an 8-bit DAC. (more details here) Their sound algorithm (which is in the repo ZylonBane linked) is called with certain parameters to create all of the sounds. If you take a look at that interactive sound simulation I linked earlier, you can import/export, which I believe just lists the same parameters.

     

    It would be a bigger lift, but technically the same algorithm could be made to run directly on hokey.

     

    Not sure how accurate it is, but there's a higher level reimplementation of the sound code here. (he's called it out as Robotron, but I'm pretty sure it's the same algorithm in Defender, just the sounds are using different parameters.)

    • Like 1

  6. Yeah, probably. It looks like I goofed in that doc anyway - in the docs it should have listed $10 for that middle value, not $20. :dunce: Serves me right for putting together a release in the wee hours. 

     

    I've updated the github releases with an updated doc, that has the correction and an example.

     

     

    • Like 3

  7. 30 minutes ago, Karl G said:

    Maybe it would be possible to have them do double the movement on alternate frames instead? The difference might not be noticeable at all.

    For sure, or perhaps off-screen enemies can have less-frequent more-coarse updates.

     

    But I think here we're seeing PMP just striving to make it arcade accurate, rather than hitting an actual implementation issue. :)

    • Like 4

  8. 1 hour ago, Karl G said:

    That one is likely to be very handy.

    Yeah agreed. Actually, it's already come in handy. Necessity is the mother of invention. ;) 

     

    There's two cases for this that I see. The regular one, where you have part of the sound naturally changing more quickly in some parts than others. An alternative case, is where use it for a long delay before the sound. (or in the middle)

    • Like 1

  9. Ok, I dropped a new 7800basic release at github. Changes include...

     

    • includes support for png files with more than expected colors. (thanks beoran!)
    • bug fix for "loadrombank"
    • bug fix for playsfx. (this one is pretty hard to trigger, which is why it's gone unnoticed)
    • data for sound effects can now change their frame-rate mid-sound.
    • updates to the 160b index-import order. (if you have a legacy project that uses 160B, you may wish to hang on to the old 7800basic, in case the new one forces you to reorder the 160B indexes)
    • Like 5
    • Thanks 2

  10. As far as the default single-stick (proline) controls go, I believe we're nailed the scheme down really well. It will actually be my preferred way of playing the game, though we intend to offer the previously discussed alternatives. (another stick in port 2, a keyboard control in port 2, possibly others)

     

    I'm avoiding spoilers at this time, because we still need to finish off some of the conversion, and then give David a chance to review before we reveal any updates. (likely his channel will be where you see it first) But people don't need to worry about extra controllers or frequent lunging for the console buttons; none of that will be required for a good experience with the game.

    • Like 9

  11. 11 hours ago, Irgendwer said:

    Of course if your display kernel is tight, even this might be a problem, but out of the blue this sounds doable for me...?

    For 2600 homebrews, a completely packed display kernel is typical. If the game has a natural break in the display 3/5ths of the way down the screen where the game already changes kernel loops it may be fine, but again here we're looking at something non-typical. So it's doable, but the game has to give up something (display less objects, be less colorful, etc.). Since there's a lot of pressure in the 2600 scene to push the visual edge, I don't see snack support as an choice that will be made. (given the added resistance of needing your players to buy-in to the control scheme)

     

    For 7800 homebrews, it's doable for the most part. Games which really push DMA (time to render display objects) may have problems with the reading of values being delayed too long.

    For 7800basic specifically, I'd need to overhaul the current interrupt system to get an extra one in the middle of the screen, which competes with future plans I had for the interrupts.

     

    Overall the specific timing requirements required here are making snack a less optimal choice. Not impossible, not particularly difficult, just constraining.


  12. I won't be able to catch this one live (my cultural background celebrates Christmas Eve, rather than Christmas Day) but I wanted to say thanks for the playing my game, and I hope everybody enjoys themselves! I'll definitely catch the show after the fact.

     

    🌲🌲🌲 Merry Christmas! 🌲🌲🌲

    • Like 7
    • Thanks 1

  13. Just a heads-up... it looks like SNACK uses particular paddle values though the range to signal particular buttons. Unlike A8, which has POKEY to do paddle AD conversion, the 7800 and the 2600 use a tight CPU polling loop to do the AD for paddle values. For reading larger paddle values, a full screen's worth of CPU is needed.

     

    So I think that SNACK as a standard for SNES controller reading in the 7800 and 2600 worlds isn't going to work.

    • Like 1
    • Sad 1

    • Can I use ROM for DLL and DL on modern carts?

    Honestly, depends on the cart+eprom. Apparently my using ROM for character strings in 7800basic caused some heartache for the AA cart designs. The fixes implemented for those may or may not be sufficient to allow for ROM based DLL and DL. I'd be very careful in testing this with the specific cart hardware you intend to use, since a corrupted DLL or DL would be tragic.

     

    • Is there any special bit in header to set? [for mirror memory] Is there any emulator/cart supporting this cart?

    bit 7 of the cart-type. A7800 and Concerto implement this bit.

     

    • Is it possible to use any emulator in RAM only mode? (all ROM addresses could be written like RAM)

    None of the current crop of emulators have this, AFAIK.

    • Thanks 1

  14. 2 hours ago, Irgendwer said:

     

    Edit: Just reread your question. I guess you refer to the table you found on the other thread. This has nothing to do with SNACK, but is a concurrent solution ("(S)NESctrl"), which doesn't support individual estimation of the buttons.

     

    Entirely correct - I saw the table and wrongly thought it was for SNACK.

     

    Your enhanced mode description sounds great. Thanks for the clarification and your SNACK support library!

    • Like 1

  15. @Irgendwer Can all of the buttons from SNES->SNACK be identified separately? If I'm understanding the docs right, SNACK returns a combination of joystick lines that could also be valid actions in gameplay. e.g. the SELECT button on the controller would generate either be LEFT+UP or LEFT+FIRE, depending on the SNACK config selected. 

     

    The PET version of Petscii Robots clocks the button data out of the SNES pad, with direct communication to the snes clock and data lines. This allows for unambiguous button combinations.

     

     

    • Like 1
×
×
  • Create New...