Jump to content

playermissile

+AtariAge Subscriber
  • Content Count

    256
  • Joined

  • Last visited

Community Reputation

331 Excellent

About playermissile

  • Rank
    Moonsweeper

Contact / Social Media

Profile Information

  • Gender
    Male
  1. Yes, definitely in the plans since it will also be useful for comparing two checkpoints in the emulation.
  2. Omnivore 2 is still in heavy development, but finally warrants a public alpha. There are some features that are missing compared to Omnivore 1; my priority here was emulation and debugging with an eye on creating Jumpman levels with custom code. The ATasm MAC/65-compatible assembler is embedded, and Omnivore will notice file changes and automatically assemble your source code when you save it in your favorite editor. The atari800 emulator core is also embedded, and currently you can step through the code and go back and forward in time (by frame) to compare the state of emulation. You can step by instruction and step to the start of the VBI or start of a frame, but that's about it for now. This week I am going to start dogfooding and creating some new Jumpman levels, and will be adding new debugging features as I go. I hope to eventually be able to step backward by instruction. I don't have binaries available yet; for the moment you'll have to install from a command line. I realize this is a large barrier to entry, but it is only temporary. On the plus side, linux users do not any special prerequisite libraries or anything. You just have to have a working C compiler. On Linux, Windows and MacOS the instructions are the same: you'll need python 3.6 or 3.7 (a Framework build on Mac, or use brew), then: pip install numpy pathlib2 wxpython pip install "omnivore==2.0a8"
  3. We'll be restarting the level design contest in earnest once I get some more testing done with Omnivore. I'm working to release an alpha of Omnivore 2 tonight.
  4. Yes! I will have an alpha version of Omnivore 2 in the next few days. It has a built-in assembler, emulator and debugger to make levels with custom code easier to develop.
  5. That's some dedication right there. I guess we in the community have to hope for a Blues repeat.
  6. Nicely done. How does one go about vectorizing something like this? Entirely (painstakingly) by hand, which must have taken forever, or are there tools to help make it less foreverish?
  7. Thanks for taking the time to do this. "If only they knew..." haha.
  8. There are a lot of creative levels in this collection, and the level editor is similar to what's available in Omnivore 2, although it uses a scripting language instead of machine code for its custom code. While Omnivore 2 won't have a scripting language (you'll have to write in 6502 assembly for custom actions), we hope to make a library of common subroutines available. There are also a lot that have more moving objects than would be possible on the Atari without software sprites. There's one with hailstones, bullets, AND bombs that fly around, like 20 things moving on screen at once Another has 8 moving platforms, ala Ride Around. The editor has a path-editing feature that would be nice to add to Omnivore 2, but given my time constraints won't be at the top of the priority list.
  9. Ok, thanks. I thought that the mega.nz download was the complete game and didn't understand how to open it. The game engine/level editor is at: http://members.iinet.net.au/~cleathley/jumpman/index.html
  10. What program can run a .jgf file? My OS reports it as: Collection Of Torture.jgf: Composite Document File V2 Document, Cannot read section info
  11. I dunno... I suspect it takes crazy to know crazy.
  12. Yes, please share it. I was not aware of the Jumpman UC project.
  13. I would like to release a Jumpman 2 this year. I have given myself a deadline of this year's Kansasfest in July to finish Omnivore 2, at which point Kevin and I will start producing levels and will put out the call for submissions. Along with the graphical level editor, Omnivore 2 will include a built-in emulator and debugging tools. I'm trying to make it as easy as possible to design levels with custom code, because this aspect is what sets Jumpman apart -- each level can have unique features while maintaining the feel of Jumpman.
  14. Jumpman uses a single PMG for the main character and uses collision detection to walk over arbitrary slopes. The method used requires sacrificing a 2nd PMG as a one pixel high "shadow" below the Jumpman character that tracks what the character is walking on. If the shadow doesn't have a collision with the floor color, it increments the Y position of the character, which could mean the character is falling or just going down a slope... won't know till the next frame when it does the check again. If the shadow has a collision with the floor color and the player also has a collision with the floor, the Y position is decremented because the character's foot is touching the floor and must be going uphill. It's a cool technique, but the cost is an additional PMG (or, I suppose you could do it with one player with a complicated variable-positioned DLI to reset the collision register for the scan line below the player's feet).
  15. Just binge'd this whole thread. Really amazing work on the graphics, level editor, source code commenting and reverse engineering; everything!
×
×
  • Create New...