Seasonal pixel harvest

[Arne]

Here are some mostly 16 colour stuff I've been working on. It's pixel-overs of existing game assets.


Starting with, Bomber Jack, a game I don't remember playing much, but it could be my memory. You know how it is, we're all old farts here.




Some indices are reserved for the background. I'm well aware that the Amiga can do more than 16 colours, but I enjoy the restriction and I guess the ST likes 16 too. I had all sorts of ideas doing these... I think when it comes to ports I'm in favour of changing things up a bit so there's something new, and maybe take advantage of some hardware quirk of the platform. Not really doing that here aside from using PAL screen height. The Arcade game which I used as reference game ran in CRT portrait mode afaik. The old Amiga (Elite) port seems to be NTSC letterbox.
I couldn't find the exact reference photo of the Sphinx (which apparently was pixeled by the sound designer). I tried to better match the cracks and stuff. The wig was propped up by support structures recently, as very early photos of it buried in the sand shows it without (the neck kind of precariously eroding). Makes it look a bit like a cobra. An ancient slab with still legible inauguration notes was erected between the paws. The sand protected it and the lower body. The Cheops Pyramid is also accurate, as is the overlap from that angle. I cleaned it up and found some indices for pushing it back atmospherically. I replaced the platforms with more figurative scaffolding. I'd give the enemies more predictable patterns with tells, and manipulation, so they don't just home in and bunch up.



WIP. The Castle level BG was apparently based on a straight-on aerial photo of Castle Neuschwanstein. It can also be viewed from the nearby hills/cliffs. I found some ref from a more attractive side angle and repixeled the entire thing, seen more from a ground/side level. One index to spare, which I might use for more high contrast foreground trees. Here my gray works as atmospheric green thanks to colour relativity.

I don't know exactly what the other levels are based on yet, but it seems the game takes place in the real world.




Fire and Ice is not a game I have ever played. Just a dumb pixperiment.




I'd turn Rick Dangerous into a Syobon game if given the opportunity. One could have a lot of fun making and experiencing unexpected trap stuff and it'd really keep the tension up as you progress. Short, compact, hard levels, but infinite lives (still counted). I think it would be more interesting than traditional telegraphed ("solve/navigate this") puzzles and action.




Zool was another one of those games I never played. I just wasn't into platform games on the Amiga as it wasn't the strength of the system. I changed the proportions and scale here. I think OCS BGs were 16 colours, and kinda garish. Sometimes it's fun to take things more in a Psygnosis or Bitmap Bros direction with longer ramps, less colours, sometimes muddier with some hue shifts so one can crossramp. I really despise candy, toy and other lazy theme levels so I'd avoid those if I were to take Zool anywhere.




Vaguely pixel related, a device I came up with but I doubt it's original in any way. It measures the time from joy switch contact to pixel intensity change on screen. I use an LDR (resistor) sensor which calibrates to a light level on boot/reset, and also normal button state. A button is read via a PNP buffer transistor. I pull 5V from the joypad/stick to operate the MCU (328P). After button detect I continually read the sensor for a change (an LDR as a fast enough response time for this, as is analog read speed). Then I output the millisec delta in either binary or bar mode to 8 onboard LEDs (didn't wire up a 7 segment for reasons). The bar display mode has a blink mode so I get 5ms granularity (good enough, turns out). In theory I think the Amiga had "upcoming-frame" input lag but many games updated every second or third frame. Still input just before that would probably count, so <20ms could be common. I tested this device using a USB pad on my Mac and found a 35-75ms lag windowed and even more in full screen (even in native rez with no scaling). The lag varies quite a bit between measurements for some reason. USB, OS queues, display interface... who knows.

I also added a Cylon scanner and some other demo mode nonsense to the device but the 328P has plenty of program space. Some more SRAM might be useful for high-speed logging.



That's all for now!

[saimon69]

Are you and Koyot1222 twins separated at birth? ^^
Give a look at the "Pixels, Pixels" thread in ppa.pl and see him doing reinterpretations and ideas too
Pixels, pixels thread in ppa.pl english translated by google

[jayminer]

Those look great!

One thing you could do if you wanted to expand the Amiga version a little would be to use some extra colors on the player character. If you use a 16 color mode you can use 16 (well 15 since once is transparent) original colors for sprites (only 4 sprites though since they would be attached and they are 16 pixels wide).
In a 32 color mode the last 16 colors in the palette is shared with the sprites.

Then it could still be ported to say the ST or other 16 color systems by just dropping those sprite colors but the Amiga version could stand out a little more!

[Tigerskunk]

Hey Arne, huge fan of your work here for many years. Also checking your stuff on Androidarts from time to time. Was always a huge inspiration for me, so this is my time to say thank you to you..

Hope you stay around a bit. Love seeing your takes on old games...

[Jobbo]

Just wanted to say these all look awesome!

I especially really love the Fire & Ice rework!

[pandy71]

Originally Posted by Arne

Vaguely pixel related, a device I came up with but I doubt it's original in any way. It measures the time from joy switch contact to pixel intensity change on screen. I use an LDR (resistor) sensor which calibrates to a light level on boot/reset, and also normal button state. A button is read via a PNP buffer transistor. I pull 5V from the joypad/stick to operate the MCU (328P). After button detect I continually read the sensor for a change (an LDR as a fast enough response time for this, as is analog read speed). Then I output the millisec delta in either binary or bar mode to 8 onboard LEDs (didn't wire up a 7 segment for reasons). The bar display mode has a blink mode so I get 5ms granularity (good enough, turns out). In theory I think the Amiga had "upcoming-frame" input lag but many games updated every second or third frame. Still input just before that would probably count, so <20ms could be common. I tested this device using a USB pad on my Mac and found a 35-75ms lag windowed and even more in full screen (even in native rez with no scaling). The lag varies quite a bit between measurements for some reason. USB, OS queues, display interface... who knows.

LDR is very slow - usually response time is somewhere between few ms and up to 100ms - comparable to measured display latency - if your goal is to measure latency then photoransistor at least (response time around 10..20us) is recommended.

[invent]

Love your work Arne, hope some of the talented coders are quietly negotiating some future Amiga games/ports with you. Agreed on the Zool visuals, would be very interesting to see how you might envision future developments of the Zool game for retro platforms.

[khph_re]

Lovely work as always,

Lemon64 has a lovely section for reworks and mockups. Nice to see that sort of thing here.

[Arne]

Thanks! Any ideas for a game to do next? Will take a look at lemon.

Re Bomb Jack: I guess a Bomb Jack game wouldn’t stress an OCS Amiga too badly, since there is no scrolling or projectiles. Bombs and such can be part of the BG, and nonmoving slowly animated stuff (coins) can just take frame turns to blit over their old selves keeping that to a minimum. Could also lock to multiples of 16. So I think the game could probably be 32 colours, but I felt like working in 16. I kind of ignored thinking about sprites but had some idea that they could be used for something outside of play (e.g. in the vertical UI, or larger 3 colour playfield effects like fireworks/explosions). IIRC sprites aren’t /completely/ free in terms of slowdown. Copper skies (or stone hues) might be cool, but I think they’ll have to be subtle (not garish) to stay faithful to the original material.

Re LDRs: When my phototransistors proved useless for this, I turned my attention to the LDRs, which I had heard were slow. So I wrote a quick benchmark test, measuring and logging to SRAM in microseconds (though this also measured an LED turn on time which probably isn’t instant). My particular brand of LDR had a gradual, curved response time, so it takes some time for them to plateau to the new level. But, there is a point early on (in the 100s of microseconds) when the level change is enough to make a verdict. I also used some circuitry on the analog power side to reduce noise, as well as avoiding LED activity at the same time messing with the power. The noise should be well below my threshold trigger level.

The phototransistor that I had in stock had no emitter output except at at /very/ strong light level (direct sun). Tried to amplify its output with some transistors, but the output was nonexistent at screen light level and then amplified noise becomes an issue. With an LDR I can calibrate the default light level and look for any abs() change, so it’s a lot more dynamic (plus my noname LDRs were in the sweet spot). With a functionally significant level change well below a ms my LDR works pretty well as the ranges I deal with are in the tens. It’s possible though that with a very low contrast change (like a sprite moving against a similarly coloured BG) the LDR would take longer reach the threshold value, offsetting the read (could add a low contrast mode though). I’m not sure if a phototransistor would be much use in this scenario though if they have a strong gain like regular transistors. And my LDRs were dirt cheap.


Had the phototransistor connected up backwards like a fool. They're reverse bias.


Re Zool: The engine seems quite competent. It’s just the theming which ruins it for me. Also, big centered character, fairly speedy movement, and no look/travel scroll-ahead made it claustrophobic. Not even sonic does proper scroll ahead… it’s so weird.

[indigolemon]

Hi Arne, these are really nicely done indeed - love the thought you have put into each of them

Regarding Bomb Jack, it was reworked very recently and an arcade accurate port was created - see https://eab.abime.net/showthread.php?t=92294

[khph_re]

Was about to say the same, McGeezer did a fine conversion.

Arne, to save you looking:

https://www.lemon64.com/forum/viewto...=43318&start=0

[Arne]

That BJ port looks quite faithful indeed. Missing some minor stuff perhaps like coin palette cycle. My mockup was more intended a quirky Amiga version doing its own random things, and I wanted to do pixel stuff of course.

Anyways: Rolling Thunder! Man or a woman ~who knows?



Changed the style to be more like RT2 with the shadow lining. I quite like the look of 2. MD version looks quite faithful. The Amiga might be able to get somewhat close visually in 32 colour mode but it's not really a game series I care much about so I won't try. The game seems o have a lot of anim frames so I think that'll eat all chipmem.

Also added some tree rendering to the Castle earlier.

[pandy71]

Originally Posted by Arne

Re LDRs: When my phototransistors proved useless for this, I turned my attention to the LDRs, which I had heard were slow. So I wrote a quick benchmark test, measuring and logging to SRAM in microseconds (though this also measured an LED turn on time which probably isn’t instant). My particular brand of LDR had a gradual, curved response time, so it takes some time for them to plateau to the new level. But, there is a point early on (in the 100s of microseconds) when the level change is enough to make a verdict. I also used some circuitry on the analog power side to reduce noise, as well as avoiding LED activity at the same time messing with the power. The noise should be well below my threshold trigger level.

The phototransistor that I had in stock had no emitter output except at at /very/ strong light level (direct sun). Tried to amplify its output with some transistors, but the output was nonexistent at screen light level and then amplified noise becomes an issue. With an LDR I can calibrate the default light level and look for any abs() change, so it’s a lot more dynamic (plus my noname LDRs were in the sweet spot). With a functionally significant level change well below a ms my LDR works pretty well as the ranges I deal with are in the tens. It’s possible though that with a very low contrast change (like a sprite moving against a similarly coloured BG) the LDR would take longer reach the threshold value, offsetting the read (could add a low contrast mode though). I’m not sure if a phototransistor would be much use in this scenario though if they have a strong gain like regular transistors. And my LDRs were dirt cheap.

https://www.amazon.com/Photodiode-Se.../dp/B00Y0L1DGK

IMHO it is also cheap and way faster than LDR i.e. can provide reliable and accurate results.

(personally to measure response time i use cheap high fps camera - for 6$ you may have over 600fps camera and measure real latency from stimulus to response on display - to verify real latency you can use LED connected in parallel to joystick so it will be visible by camera at the same time as display - then everything is simple - you can measure not only display but also computer response)

https://blog.robertelder.org/recordi...rry-pi-camera/

Camera allow also to judge for complex response (like only partial object redraw etc).

[Arne]

Re Electronics: Using a high speed camera can get a little tedious if you need to make, say, 10 measurements in 10 games to get a nice average. I suppose it is possible to write a script that analyses the video information automatically, but without, then there's some manual work reviewing each video. Ultimately I don't really have any interest in RPi linux/dev wrestling, and never bought a cam for my Pis. I tried using the RPis for Amiga Emulation but really do prefer to just use my main desktop with FSUAE, or my actual A1200.

A camera seems useful for capturing scanline action.

600FPS though is... 1.67ms? Less resolution than my system, which is some 8-9K samples per second with the default analogRead speed (around 100-120us). LDR detection can actually happen on the very first analog read. 100% certain on the second read (I don't need to wait for the LDR level to flatten out at the actual new light level, which does indeed begin to happen at several ms in my benchmarks). Also, if a photodiode is read by analogRead, then it is at least subject to the same read time.

I could subtract some of the estimated read time but didn't bother. It's well in the sub-ms, below the granularity of my crude display. Conceivably I could use something like an LM311 comparator and try to employ faster digital reads, but then I need to set a threshold value with pots so it's more fiddly (unless I use digital pots somehow).

A photodiode (on linked module) is not quite the same as a phototransistor in behaviour iirc. No price in your link, but it looks like a €5 module, which might be the cost of my entire populated board if it was similarly China mass produced (but it's of course just a one-off... still, I might whip up a PCB+BoM in KiCad for funsies). I could probably switch to a cheaper (€1-2) ATTiny as the 328P is overkill, but if sold as a pcb kit it's better to rely on a socketed 328P as that's useful in other projects and well supported because of the UNO.

5 euro will get you 100+ LDRs in the cheapest listings. Bulk Photodiodes/transistors are not quite as common in e.g. ebay listings, but it looks like they're 2-3x the unit price of LDRs, so in the cents and not too bad. Still don't have any, but might pick up some cheaper F3/F5 ones for experimentation if I get the chance! Been many years now since I China binged so I make do with what I have stocked.

Edit: I managed to change the ADC prescaler and speed up the reads. It seems a higher speed doesn't introduce noticeable noise... it's around +-0.75 out of 1024. I suppose a CRT or flourescent/PWM strobe light might be an issue though. Anyways, here's the reading of an LED coming on, using a cheap LDR. It's hard to say where to put the detection threshold in case there are animated sprites and such. Probably best to find a spot with a high intensity change.

Time____Level
0 micros, 642 (Just before LED on)
24 micros, 636
40 micros, 593
60 micros, 559
80 micros, 528
100 micros, 502
116 micros, 478
136 micros, 456
156 micros, 438
176 micros, 419
192 micros, 404
212 micros, 390
232 micros, 376
252 micros, 364
268 micros, 352
288 micros, 343
308 micros, 332
328 micros, 323
344 micros, 315
364 micros, 306
384 micros, 299
404 micros, 291
420 micros, 286
440 micros, 279
460 micros, 273
480 micros, 268
496 micros, 262
516 micros, 257
536 micros, 252
556 micros, 248
572 micros, 241
592 micros, 239
612 micros, 235
632 micros, 231
648 micros, 225
668 micros, 224
688 micros, 220
708 micros, 217
724 micros, 214
744 micros, 211
(it's quite flat later on at 2-4K us)

[alain.treesong]

@Arne
Thanks for all these beautiful graphics.
I was a big player of Bomb Jack (on Amstrad CPC) when I was a kid and I think this is probably one of the best game of the Amstrad.

With your consent, I would like to do a small prototype of a bomb jack like during the next weeks on Amiga 500 using the graphics tou have done. Do you agree ?

I think it will be cool to see all that moving smoothly on our cool old toy (aka A500).
I don't know how far it will take me. At the very least, I could include the scene in a demo (for example for a greeting or credit part).
To have an idea what I can do, you can see what I have done during the last 3 years on Amiga : https://demozoo.org/groups/111822/

Bye.

[Arne]

It'll be a fair amount of work, though maybe manageable as a "vertical slice". Since there's already a decent port, this would have to be something else.

I have fiddled a bit on a more complete "sprite sheet" that I might post later. I need to test out the animations... usually animations don't work at all when I just draw them one after another, so they won't be much use that way...

[gimbal]

Love it all. Especially the Mighty Bomb Jack castle background, amazing what you can do with only a few colors.

[alain.treesong]

@Arne

Nice. I should be able to make an assembly relatively quickly that will work on a 500. This will give you an idea.

Indeed, after that, the concept should be improved to make it better than the original. To see if something is done one day.

For some objects, especially bomb jack, it would make sense to use sprites. In 16 colors mode, sprites have a separate palette (the 16 colors from 16 to 31). I won't go into details that you probably know. In any case, think about making your character (or both, if there are two players) in a more or less fixed palette whatever the level. Moreover black (color 0) could be different from the non transparent black you use for Jack.

[alain.treesong]

@Arne

In the end, it only took a few hours to make this simple POC with your nice graphics.



[ Show youtube player ]

The implementation is rudimentary: there is no collision detection except when picking up bombs and there are no platforms. I added 5 flying saucers with simple movements as well as the "fly" that just follows the player.

As I didn't have detailed animations of Jack, I kept it simple. The movement routine (walk/flight) is very basic.

This gives an idea. It is very smooth (50fps on a standard A500) as expected. Amos is quite comfortable with fixed screen implementation, especially in 16 colors.


What I will say from a graphical point of view:
- the graphics are beautiful (a small raster in the sky would perhaps magnify the whole even more)
- Maybe we confuse jack with the scenery a bit. Jack is a sprite, as well as the fly. So the separate palette should help to solve the problem

See what can be done with it.

I discovered your site via your profile on this forum.
We could make a demo (in the sense demoscene) with several of your graphs for example. Or I can give you the sources (it's Amos and I saw that you know).

[Arne]

Are you doking the mask Base addresses to get full 16 colours? I seem to recall having to do that in AMOS (with icons at least). Doesn't save in the banks either so it has to be re-done each boot. EDIT: Nm. Seems I didn't use the BG colour here as an opaque colour. I sometimes do it for my 8 colour projects to get an extra solid colour.



The sky colour vary per screen so I think the player will be readable. The skies could use a subtle copper effect but nothing too wild. I think I might be more tempted to use the sprites for some kind of effect or bonus items which need to pop and flash (palette animation without distorting the main graphics).

I actually haven't made much progress on the gfx as I've been engrossed in dumb PCB activities. Sending them to the manufactorum soon though so maybe I can return to some older projects.

MCU motherboard with some more components on the back for more stable analog:

Module that can be populated as an Amiga Drawbridge or Input lag tester: