Krull - Recreation of Arcade Game

[+saxmeister]

It's definitely a gosub gone wrong in the other levels. I know the issue, I just need to fix it.

 

I've been slammed with tons of stuff and haven't been able to get back to this. I'm hoping by May to be freed up again to work on Krull. Sorry for the delay. But I do have most of the artwork for the second and third levels ready. I just need to implement them. Then I'll get back to making the first level work properly.

 

And I'll get those glitches worked out. There is no double-buffering yet, but I will add that. It will need it if I get more than 10 boulders on that first screen.

 

Thanks for the interest and support!

[PlaidMouse]

This is looking great! I'm a big fan of the movie, the Atari 2600 game, and the arcade game. I use to play the arcade game most Saturday mornings when I was in my mid-20s. Very cool stuff. Thank you so much for doing this @saxmeister! 

[+saxmeister]

Just a heads up that I am still working on this but have run into memory issues and have had to begin working with banking. This is where my lack of experience is causing a major hurdle.

 

The title screen itself will run but I start getting into the additional global graphics and I run out of room. And banking doesn't work the way I think it does.

 

[Trebor]

Hopefully, the below references may help.

 

Threads:

Bank Switching Template?

 

Bankswitching and ROM sizes

 

Accessing alphadata tables when bankswitching

 

Trying to bankswitch ... having troubles

 

 

Documents:

Bankset Bankswitching - An overview of the homebrew bankswitching scheme created by Fred Quimby, in collaboration with Mike Saarna.

 

Atari 7800 Bankswitching Guide - Eckhard Stolberg's bank-switching bible for the 7800.

[+Muddyfunster]

5 hours ago, saxmeister said:

Just a heads up that I am still working on this but have run into memory issues and have had to begin working with banking. This is where my lack of experience is causing a major hurdle.

 

The title screen itself will run but I start getting into the additional global graphics and I run out of room. And banking doesn't work the way I think it does.

 

My approach with bank switching is to split my graphics between a) stuff I only need for this level / world and b) stuff I need everywhere (player, explosions, shared assets). 

 

Anything in a) goes in the executing bank and anything in b) goes in the last bank, which is visible to your program from anywhere.

 

So using EXO as the example, title page in bank1,  level code + tiles for level 1 go in bank 2, mapfiles in bank 3 and common assets go in the last bank. There is nothing stopping you jumping to other banks to do stuff, as long as the place you "drawscreen" or doublebuffer flip" is where the local graphics are. 

 

If you want to zip up your project and PM it to me, I'd be happy to take a look.

 

 

[Deteacher]

This is fantastic!  Krull has always been one of my all-time favorite games.  The sound effects and music are amazing!

[thegamezmaster]

Just found and looks promising. Anyone know what form or format this will be in? Physical or digital only? Interested.

[Ecernosoft]

On 3/21/2022 at 10:45 PM, ZeroPage Homebrew said:

Hopefully you'll be able to make it an option for those who have twin stick setups. ?

 

- James

Yes, that would be nice. ? 

As someone who owns a real atari 7800, and a modified 2600 (My 7800 is stock), I appreciate when people take advantages of people who aren't sacreligous (OK, OK, I use emulators too!!)

and have a real atari 7800, 2600, or 5200 (Those people exist BTW) that people take advantage of that.

By the way, my pause button on my 7800 doesn't work, so if anyone has a spare pause button (or compatible switch), please let me know!

[Traxx]

Any progress to report?

[+saxmeister]

Yes, @Traxx, it's still on hold while I work out bankswitching and more performance tweaks to my video and game routines. This particular game was a pretty big bite for my beginning efforts in gaming logic. I'm wrapping up some other projects that will help me get there. Don't give up hope! It will happen - just not as soon as I would like.

 

Edited September 26, 2022 by saxmeister

[+x=usr(1536)]

Just curious: could this potentially provide an engine for other Reactor-hardware Gottlieb games?

 

(And, yep, I'm also looking forward to seeing how this progresses - I loved Krull when it hit the arcades, but only very rarely saw it.)

[+saxmeister]

Hmmmm.... I never thought about that. I would need to look at the other games to see how similar they are and go from there.

[Ecernosoft]

On 3/18/2022 at 5:35 PM, saxmeister said:

I had posted some test work on this before, but I started getting a little more serious with this. A test started coming together rather nicely, so I'm going to attempt to recreate the arcade version of Krull on the 7800 as closely as possible.

 

This is my first "big" game, so it will take some time. I'm learning with each step, so it will come slowly. I'm learning how to properly structure the game and learning things such as collision detection and bank management. It's a lot to learn at once, but if I can do it, many of you can as well. The 7800basic environment is amazing! I can't thank the devs enough for this tool.

 

I don't have the original source code to work from, so I'm winging it here.

 

• Ripped the graphics from the arcade
• Ripped the font from the arcade
• Recreated the title screen with the limitations of the 7800
• Recreated the first level and I'm working on the AI of the rolling boulders
• Got the movement of the lead character "Colwyn" working with all frames of animation ripped from the arcade machine
• First collision detection of the shards of the glaive and added scoring for this

 

FIRST TESTS

Link to JS7800: https://raz0red.github.io/js7800/?cart=https://atariage.com/forums/applications/core/interface/file/attachment.php?id=919271

 

VERSION 0.4

Link to JS7800: https://raz0red.github.io/js7800/?cart=https://atariage.com/forums/applications/core/interface/file/attachment.php?id=926309

Nice job so far!

[Inky]

When this comes out, it's a mandatory buy from me!

[Ecernosoft]

VERY MUCH SO!

[+saxmeister]

Work still continues... I'm going level by level, but as a huge fan of this game I had to add something that hardcore fans would appreciate. I'm adding a variation of the original game's Easter egg.

 

If you know, you know...

 

[+x=usr(1536)]

21 minutes ago, saxmeister said:

If you know, you know...

It complements the Atari ST well

[+saxmeister]

I've finally gotten more comfortable with the 7800 and 7800basic and decided to tweak the title screen and go with 320B mode.

 

I still don't think this means I'll be doing the rest of the game in 320B mode - 160A/B just seem to perform so much better and the arcade game keeps lots of sprites on screen at once.

 

JS7800 Link: https://raz0red.github.io/js7800/?cart=https://forums.atariage.com/applications/core/interface/file/attachment.php?id=1023050&key=ee810367f3156b504394c9127cc5e3a5

 

Note: the colors aren't accurate on a7800, so I recommend JS7800 or the real hardware.

krull_13.title.bas.78b.a78 krull_13.title.bas.78b.bin

Edited April 30, 2023 by saxmeister

[+x=usr(1536)]

Nice title screen!

 

Nothing wrong with 160B.  There're some really good-looking games using it, and anywhere you can save cycles is a Good Thing™ 

[Trebor]

13 hours ago, saxmeister said:

Note: the colors aren't accurate on a7800, so I recommend JS7800 or the real hardware.

JS7800 and a7800 use similar palettes with variances in saturation and brightness.  For both emulators, and with real hardware, a few colors will vary considerable depending if a cool, warm, or hot running console is selected, as well as tweaked viewer preferences. 

 

If the difference being noticed is color artifacting which can occur heavily in the 320 modes, this will vary among real hardware, if CRT simulation is being handled by the emulator or FPGA console simulation, which display type (I.E. LCD, OLED, Plasma, CRT, etc.) is being leveraged, video mods (Some of which, S-Video and higher, completely eliminate color artifacting), to name some items the affect the end results.  High caution needs to be yielded when working with 320 modes as consistent/reliable colors may not be possible across all setups.

 

From the aforementioned link:

"If you're designing graphics and fonts for 320 mode display, and you wish to minimize artifacting, you need to ensure that any bright or dark pixels are horizontally followed by 1 or more pixels of the same luminance."

Game example:

Spoiler

Tower Toppler via A7800 Emulator - Simulated similar to Modern displays (I.E. LCD/OLED), S-Video, RGB results:

 

Tower Toppler via A7800 emulator - Simulated similar to RF, Composite via a CRT: 

 

 

[+saxmeister]

It's really a difference in rendering, not necessarily colors. The glyphs in JS7800 render properly and are filled and color cycle. In A7800 the glyphs aren't filled and only the edges color cycle.

[+Muddyfunster]

I think the behaviour of A7800 is consistent compared to real hardware. 

 

Under JS7800 the glyphs pulsate in colour, on real hardware they do too, but they go to black almost due to the artifacting that Trebor mentioned (as you noted, just the edges cycle).

 

Quick and dirty video from my NTSC console:

 

[Trebor]

1 hour ago, saxmeister said:

It's really a difference in rendering, not necessarily colors. The glyphs in JS7800 render properly and are filled and color cycle. In A7800 the glyphs aren't filled and only the edges color cycle.

@Muddyfunster beat me to the punch. 

 

JS7800 visually seen behavior is incorrect. 

 

Here is original hardware via Concerto:

A7800 is demonstrating the proper end results as seen when played under original hardware.

MiSTer FPGA also provides the same results as original hardware and the A7800 emulator.

 

For testing purposes, original hardware is, of course, best.  MiSTer FPGA and A7800 emulator are the next best bet.

 

JS7800, while a very good emulator, it is not good enough to be a reliable testbed.

[+Defender_2600]

21 hours ago, x=usr(1536) said:

Nothing wrong with 160B.  There're some really good-looking games using it, and anywhere you can save cycles is a Good Thing™ 

 

In converting 16x16 sprites/tiles, both 320C and 320B modes consume same cycles (2 bpp) and consume half cycles than 160B (4 bpp), therefore both consume almost double cycles compared to 320A (1 bpp) and the same cycles compared to 160A (2 bpp).

 

However when we convert graphics to use 160 mode, we usually use a width less than 16 pixels, for example 160B sprites/tiles, scaled down to 8x16 pixels, consume almost the same cycles as 320B/C 16x16 pixels. And therefore the 160A mode consumes fewer cycles than the 320B/C simply because the single pixel has double width and allows us to use fewer pixels (compared to the square pixel) to cover the same width of graphics.

 

[+saxmeister]

Ouch, I was hoping that JS7800 was emulating more correctly. Especially since it was behaving the way I wanted it to behave. 

 

Oh well, back to the drawing board/GIMP. Thanks so much for the feedback, guys. It is ever so helpful, especially since my real 7800 isn't hooked up right now.