English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 05 May 2022, 20:29   #21
alain.treesong
Aghnar
 
Join Date: Jan 2019
Location: France
Posts: 125
I don't know if I understood your question but you can simply get the colors saved in a bank with "get sprite palette" or "get icon palette". If you need to set the color of sprites in a 16 colors screen, you can set the values with the "palette" or the "colour" instructions in the index 16 to 31.

Indeed for the background color, I changed the black color and the index in the sprites in sort that the black used by the sprites is not transparent. By the way I did a mistake by setting a brown value instead of the originial color you use. Sorry.

Of course you are right: a small raster will be perfect.

I don't have a lot of time too. As I mentionned already, if you are interesting in releasing something for the A500, the simplest is probably to do a little demsocene production for A500 using some of your gfx. But this is just an idea
alain.treesong is offline  
Old 05 May 2022, 22:42   #22
Arne
Hobby/Indie gamedev

Arne's Avatar
 
Join Date: Jan 2015
Location: Southern Sweden
Posts: 71
Oh, I meant that when I do 8 colour bobs, I actually use 9 colours if we count the 1-bit mask as a colour like you would on a sprite sheet image. The Amiga stores the masks separately in a certain base memory location that you can carefully doke (16-bit wide) from AMOS. It's also useful when you want to fast-blit e.g. 12 pixels wide icon blocks fast. You doke 12 set bits into their masks at "Icon Base".

I didn't decide on a palette order yet. It takes some consideration, as there are fun things you can do with blit modes in AMOS. If you structure your palette carefully, you can do transparency, shadow and glow effects cheaply. Usually you have to order the colour indices in pairs of 2 or 4 for it to work though as we're dealing with bit logic. Might be doable as I have 2 reds, 2 yellows, 2 blues, and 4 grays including black. Might be able to do a 1-index-offset effect at least (e.g. a hit flash or pulse). I'll have to look at some feasible palette layouts.

The sky blue is supposed to be index 0. No, wait, that makes the overscan the wrong colour. Ah, yes, this is also why I doke. This way black can be index 0 and still opaque on objects! AMOS auto mask stuff ruins an index so I do masks manually via memory manipulation. It also doesn't save masks in banks. IIRC, I save my reference masks in a separate memory structure for quick doking.

I always set up my palettes manually because truncating to 4+4+4 bit can lead to some odd hue drifts, and dealing with reindexing done by Photoshop or DP is a bother. I also write my own asset loader/grabbers and bank handlers rather than using the utilities. For custom fonts I like to use FED. Fortunaately AMOS handles spacings, kernings and such correctly.

I was thinking the copper could be used as a cheap laser attack by one of the bosses. It travels up and down, turning its side lasers on and off by setting a few scanlines to some laser colour. This way no line drawing or clearing has to be done. Maybe just some telegraph-attack chargeup muzzle plasmaballs. Player has to time a vertical transition between.


Just sorted the frames a little, added a chest and stone blocks from NES MBJ. Still no player anims...

Last edited by Arne; 05 May 2022 at 23:00.
Arne is offline  
Old 05 May 2022, 23:01   #23
alain.treesong
Aghnar
 
Join Date: Jan 2019
Location: France
Posts: 125
Ah, ok. Interesting.

In the idea of playing with bitplane and index color, perhaps this little thing can interest you as it appears that you know amos very well :
https://github.com/alain-treesong/am...threePlayfield

Nice. The sprite sheet is more complete.
About the copper : a lot of thing are possible but the instruction "rainbow" provided by Amos are a bit limited and you will have probably to do things manually. But you already know that probably.
alain.treesong is offline  
Old 06 May 2022, 09:58   #24
Arne
Hobby/Indie gamedev

Arne's Avatar
 
Join Date: Jan 2015
Location: Southern Sweden
Posts: 71
The rainbow command alone is quite clumsy for setting up gradients, yeah. It's been a liitle while since I rainbowed, but I think you'd jist set up a 240 line list and then configure each line with Rain. I often would use it to line dither the sky gradient but it occured to me that one could use the effect for a tiny screen-wide copper bar that's a laser attack. You'd have to store the old background line values somewhere ofc. I don't think one would need to touch the more advanced COP commands. Colour index here would not be 0 black, whatever the sky ends up being.

I remember using rain to do a classic demo type rotating copper bar wheel once, which needed some LUTs for the rotation overlapping as there's no actual z-depth to a 1D array.



For sprites, I might have mentioned it, but I think I’d use those for decorative particle effects which tend to use less colours, and flicker won’t be an issue there. It's really a waste to do flat or low colour effects using bobs which then need to blit in 4 planes. I think with 50fps, one could alternate 8 3-color sprites to get 16 transparent ones. Little explosions, Kirby-style GET debris/stars and sparks (8). Collision puffs and trails behind the player (2). And the pickup scores (4). Maybe Enemy/Boss bullets (2). A vertical boss beam could be done using a single sprite.

Some of the 4 sprite palettes could flash in garish colours for sparks, whilst the BG palette remains static (colour animation here would require extra image frames unless certain blit modes can be used).

I think computed sprites can introduce a little slowdown (at least in interpreted mode) as they need to be computed.

Last edited by Arne; 06 May 2022 at 10:36.
Arne is offline  
Old 06 May 2022, 19:28   #25
alain.treesong
Aghnar
 
Join Date: Jan 2019
Location: France
Posts: 125
I spoke in fact of the rain command.
Beware, if you define a too high "rainbow", you will lose some perf due to the Amos implementation. So if the target platform is the A500, defining a too high rainbow can
lead to some slowness

Don't remember if I mentionned if, for the sprites, in the little bombjack POC I did with your gfx (by the way, do you want the adf ?) I use sprites for jack and the fly. I use 4 hard sprites (sprites 0,1 for jack, 2,3 for the fly ). It remains 4 hard sprites of 3 colours. I think it is a good thing yo use sprites for main objects but of course different strategies are possible.

In my experience, the problem with computed sprites is that the implementation in Amos is not perfect and we never know the behaviour of all that. I think that we shouldn't think with the interpreted mode.

All that is interesting. What is your plan for your bombjack like? If you do it in Amos, I might be able to help you a bit

Last edited by alain.treesong; 17 May 2022 at 20:25.
alain.treesong is offline  
Old 06 May 2022, 19:53   #26
saimon69
J.M.D - Bedroom Musician

 
Join Date: Apr 2014
Location: los angeles,ca
Posts: 2,583
If you keep plain BOBs you can have everything same 16 color palette beside player sprite; add some copper in background and the result is still light years better than Elite implementation
saimon69 is offline  
Old 09 June 2022, 14:55   #27
Arne
Hobby/Indie gamedev

Arne's Avatar
 
Join Date: Jan 2015
Location: Southern Sweden
Posts: 71
Well, I derailed and did other stuff. I'm not really sure if AMOS is appropriate. It might sufficient since the game is rather simple with no scrolling. My idea was to keep it 4 bitplanes blitting since I've already done some of the bob-work for that. If I made the player a sprite I'd have to redo it to better use the expanded palette since I then would have 32 colours, which changes the whole palette philosophy that has already invested in. I was thinking a bit about the ST too, which iirc has 16 colours and is kinda poo at scrolling, so this kind of game might work there.

Anyways: Monster World (edit: Land) re-do:


And:

KiCAD adventures

Made PCBs, including the Input Lag Tester / Amiga Drawbridge thing, ft. 7-segs and some GUI buttons.



Also made keyboard+joypad PCBs for my fantasy/alt-universe compact Amiga. Got some firmware working the other day. Might write a USB interface for it too. It has a very custom keymap (layers, compose key) so it likely needs OS-side attention as well... not fun with three messy modern OSes to support.

Last edited by Arne; 10 June 2022 at 10:55.
Arne is offline  
Old 23 June 2022, 11:56   #28
Arne
Hobby/Indie gamedev

Arne's Avatar
 
Join Date: Jan 2015
Location: Southern Sweden
Posts: 71


Katakis pixel-over with a new <16 colour palette. At some poinr I want to experiment with 32 colours... seeing how Fly Harder looks pretty snazzy. A lot of the Amiga shmups are a bit... "trudging". I remember enjoying Blood Money back in the day, but I don't think I was aware of how fast and busy Arcade shmups were. The Amiga has a whole bunch of unknown shmups which were probably made by small devs, maybe as their first big project. There are a few cool faster and more fluid ones, like Necronom and Ziriax. Mega Typhon is pushing a lot of objects on screen. Seems inspired by Raiden, but the BGs are too noisy which is a real shame (8 colour blits for terrain?). I never played Saint Dragon but it looks nice.




Amiga Cube from a while back. With a Larson Scanner on the front because why not? Specs unknown.




Amiga 1001 idea. The A1000 case design has grown on me. Here I wanted to chonkify & mix in some PC-8801 FE bits. Often I've thought that the Amiga could've used a chunky pixel mode but now when I think about it, the Amiga already had quite fancy pixel manipulation capabilities and slightly better performance which would've gotten dated fast anyways. I used my A1200 with a TV so the highrez modes were not useful, nor was the 256 colour mode as it was hard to make assets for.

So here I'm imagining a simpler A1200 released earlier, with just increased sprite capabilities, and an upgrade path to an IDE HD0 and more Fast Mem. More positioned to compete with the Megadrive and SNES which were released late in the EU. Still attractive as a computer and development platform, but not competing with wonky early 3D PC-DOS. Hard to say how to boost sprite capabilities though, as chip was already taxed. Maybe a new sprite GPU board with dedicated 512K VRAM... it'd be kind of okay if CPU access to sprite images was bottlenecked (though not the position&pal registers).

CPU and memory could use a small upgrade too. I've heard that in some respects the 68K wasn't much faster than the old 6502.
Thought of a new logo, working in the A shape as a checkmark is kind of nonsense. Imagining it on a sort of Playstation boot screen with (generated) sound chime.

Last edited by Arne; 23 June 2022 at 12:21.
Arne is offline  
Old 25 June 2022, 12:26   #29
Arne
Hobby/Indie gamedev

Arne's Avatar
 
Join Date: Jan 2015
Location: Southern Sweden
Posts: 71



Looked into Mega Typhoon a bit, though I don't have the ADF so I couldn't investigate further. Speculation: It seems like it uses 8 colours for the background, then 7+trans for the enemies... so I'm guessing OCS/ECS Dual playfield 8+8 which might speed up moving blits.
Not sure if it does flipping on the fly (or scaling... but that could be Deluxe Paint artifacts), but it appears like terrain is not tile-aligned, but instead overlapping decorative chunks spam, kinda like in the Lemmings editor. The screen is less wide, which doesn't hurt a vertical shmup and probably lightens memory load. Possibly it uses the copper on the terrain and enemy layer to recolour areas.

The player ship might either be an attached 15 colour sprite (perhaps with the grays occupying the transparent indices?), or just stacked 3 colour sprites. The score and bullets use the same palettes, which sometimes change on the fly (weapon change and death/spawn). Not much bullet flickering... I guess the limit is 8 per scanline, but since it's vertical it can make some neat very spammy bullet columns (also packs 3 bullets into 1 sprite width and alternates sideways for sixtupled effect) (also, moving up/down doesn't compress or space the bullets). Pickups and Explosions might be a bob-sprite mix. Missiles are Bobs. Projectile speed probably helps to give the impression of more objects too.

Graphically it'd probably be more legible with more muted BG layer colours and less greebles.

Edit:



11 colour pixel-over of Valley of Rains (by Zosya Entertaiment, 2019, ZX Spectrum 48K). Mostly just adding colours.


EditII:

Castlevania pixel-overs,staying pretty close to the originals (below). But, using a possibly global 32 colour palette with sprite colour features for particles/projectiles/gibs. Smaller scale than SotN/DS/X64K/Snes, but larger than GBA. Just a feel-good size really, not sure if practical. It's a slow game so 32 colours might be alright. OCS target, not AGA.

Last edited by Arne; 30 June 2022 at 22:44.
Arne is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
Best pixel art package? Marchie Retrogaming General Discussion 19 16 February 2021 17:47
Alien Breed II title pixel by pixel logo removal dex project.Sprites 17 06 May 2020 15:23
Being a pixel... Shoonay Nostalgia & memories 13 18 February 2014 15:52
Pixel coding Akira Retrogaming General Discussion 9 07 March 2012 22:20
Ateobus and pixel 64 attila06 support.Hardware 9 23 January 2012 21:15

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 00:59.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2022, vBulletin Solutions Inc.
Page generated in 0.09158 seconds with 17 queries