Jump to content

LS_Dracon

Members
  • Posts

    1,002
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by LS_Dracon

  1. Here is, the top is how it scrolls now, 4 pixels every 8 frames, so if the bomb is on top of target at frame 7, its scrolls 4 pixels next frame and you think you miss the target.

    But at bottom you see how it would smooth scrolls (a pixel every frame). The target shift 1 pixel to left every frame and you don't have the illusion it would hit.

    The problem is the illusion of 4 pixels scrolls (PF) vs 1 pixel smooth scroll (bomb) which let to mistakes. That's why I think if the bomb moves according the PF (and not the player) this would reduce this illusion.

     

    This is not a really big problem BTW.

    post-10940-0-27803400-1447768664_thumb.png

  2. The point is you miss that shoot.

    In a smooth scrolling, that bomb will miss the target anyway.

    My suggestion is about better feeling on the bomb trajectory. There's others ways to reduce the oddity, if the screen scrolls every 8 frames, you don't need to move the bomb 4 pixels every 8 frames, to tie with scrolling, you can move the bomb 2 pixels every 4 frames, in a way to reduce the discrepancy of 4 pixels PF shift.

    I don't know if going to work, it's just a suggestion.

  3. Technically you would miss that target, because the playfield scrolling is delayed by 8 (?) frames. The problem is the illusion it would hit.

    I think the bomb horizontal movement need to be tied with playfield scrolling, even if it means "choppy" trajectory.

  4. Note on tv picture (cart) the background is light blue, (just like the title screen?)

    Perhaps the source is not the final revision.

     

    Arkyology and now Birthday Mania, what a great year, how many games are out there just waiting to be re-discovered?

  5. It's funny when people know "hmove" bars exist but have no clue how it works :)

     

    But based on a picture I think it's accurate. I would remove the "projectile" when hit the candle, as it is the standard on most atari 2600 games.

    • Like 2
  6. I'm not making progress on this, but basically I'm trying to put more objects on screen.

    Theoretically I can add more text lines or redraw the sprites without a blank area on screen.

    A good code would use all 4 sprites and draw a bitmap image with 32 pixels wide by many scanlines I want.

     

     

    What are you using to get code on the Odyssey?

     

    How to load the code on odyssey? You can check the C7051 flash cart, I don't know where you can buy, BTW.

  7. I'm testing a kernel like the Atari 2600, where we can update graphics on the fly while electron beam is drawing the image.

     

    Unlike on Atari 2600, on Odyssey 2 we can't change the graphics while the video chip is "on", only at vblank time.

     

    The trick here is disable the chip before Hblank and enable when the scanline starts, then uses hblank time to made the changes.

     

    The processor is really slow, I can change only 1 register every scanline, but this is much better than nothing.

     

    I'm still testing, the image shows background color changes (black is the "hblank" area). The difficult here is keep the picture stable, which I did.

     

    I can't use whole screen, so the game screen must to stay between two grid lines, that's a "safe area" for display the graphics.

     

    If it works like I'm thinking, the possibilities are endless...

    post-10940-0-33930500-1443567087_thumb.jpg

    • Like 5
  8.  

    As for cartridge adapters, I am unsure what kind of footprint these would be. Would it be some doodad that slots onto the side? (my original idea) or would it be like the 2600 adapter for the 5200 that plugs into the top? I originally wanted to make a massive add-on with like 16 cartridge ports but this is ridiculous (and I knew this- I was going for ridiculous) and absolutely unsellable. It'd just be a fun thing to make.

    As for cartridges adaptors, is possible to plug them by a cable? Like an external HD?

     

    So you can plug them each other, see the image :

     

    post-10940-0-73938800-1442969866_thumb.png

  9. Thanks for the answers.

    This is going to be a great tool for homebrew programmers, because we can keep this console to test the game on "real hardware" besides emulation, sometimes we need to do a quick test in the code and turning on/off many times in a short period of time reduce the life of old consoles.

    Also I don't want to have a Colecovision, but I would like to have one or another game/homebrew for this system, then I could play on this machine.

    I mean, we don't need to be a collector to buy games for others consoles, this certainly will help the community as a whole.

    All controllers will use USB and there will be 4 USB ports ideally. This will allow for game controllers, keyboards, and mice.

    Can we use it as a combo? I mean, for a Intellivision, use the controle for directional and buttons and keyboard for the numpad?


    Speaking of new cores, these are my goals for the project:

    SNES, Genesis, and Neogeo (and TG-16).

    I think NeoGeo will be a great addiction, because we don't have a affordable alternative for AES, just the consolized mvs (still more expensive than your project goal).

     

    Good luck!

  10.  

    ...

     

    Now the real reason for this thread: I wanted to talk about the one bug in E.T. which I personally felt - even way back in 1982 - was its Achilles' Heel, and which is still not fixed in the Neocomputer.org rom. When exiting a pit, as soon as E.T.'s neck finishes retracting, his entire sprite moves down one pixel. The fallout of this is that if one exits a pit from the top of it (as opposed to the bottom or the sides), as soon as E.T.'s neck retracts, his sprite shifts down a pixel, so his feet touch the pit, and he falls right back in. Even after coming to grips with the too-exacting collision detection, one would still be very easily confounded by this subtle bug.

     

    It would be interesting to see if this final bug could be squashed. Then all that would need to be done is to implement some means of preventing RNG-abuse and the game would be, in my view, perfect.

     

     

    The problem is not when ET retract his neck, it's when you walk, his feet downs one scanline and touches the pit.

    So when you press up to exit the pit, you still pressing up when the playfield changes and ET walks up.

     

    This was fixed by me year ago but I not made the rom public because it's based on "ET fixed" hack and it's not my work.

     

    Anyway here's the hack, I don't want any credits for it.

    ET_feet_fix.bin

    • Like 1
  11. There is a code to generate a random number on bios, but you can code it by yourself, not a big deal, also the random number code is missing on G7400 bios (european Odyssey 3) because they needed the rom space for other stuffs. So it's not a good idea to use this code else the game will not work properly on Videopac 7400.

    Berzerk would be perfect on this system, there is the homebrew Amok, but it uses the running man from the alphabet, which doesn't looks good as the robots.

    • Like 1
×
×
  • Create New...