Making a Will o' Wisp in bitmap mode

[Sergioz82]

 

 

This is a project I am currently working on.

I wanted to create a trail behind a moving sprite (the yellow sphere). The core of the idea is the classic snake concept but expanded to take advantage of the bitmap mode. I also added a "spiritual flame" effect that is triggered when the sphere is not moving. The effect is not pre-calculated as the bitmap is modified real time with random values. There is still some polishing to do (i.e improve the flame effect and the vertical trail color pattern) but now I have the proof of concept

 

I think it can be used to make projectiles, meteorities, ghosts, boat wakes and so on..

 

My idea is to make a fixed screens platformer with small puzzles to solve by using the sphere's abilities, but there is still a lot of work to do. The next step is learning XDT99 and bank switching. 

 

In more detail, the trail is made this way:

 

• the head is an empty 8x8 circle pattern with its color pattern. In each cycle the program reads from VDP the bitmap at head position, SOCB with circle pattern in next position then writes the resulting byte(s) back in VDP
• the tail has the same pattern of the head and works the same but SZCB with circle pattern instead
• the head writes position information in a buffer that has to be as long as the desired lenght of the trail, i.e 16 pixels means 16 entries in the buffer. When the head moves it writes its next position in the buffer. The tail reads the buffer in sequence.
• the bobbing effect is a very simple set of instructions that increment a -2 to 2 offset each 8 pixels
• I had to implement a collision detection between head and tail because when they overlap the tail doesn't work properly and it leaves stains on the screen, so when they overlap the head stops drawing (you can notice this in narrow turns)
• the flame effect is made by switching to an alternative head routine. It starts with a 00 byte pattern, then a random 0-255 number is generated to SOCB the pattern. Then the resulting byte is SZCB with a cutout pattern to turn off the bits around the edges to give it a rounder appereance.

 

 

 

 

[+Vorticon]

Very nice effect.

[Retrospect]

It's great.  I love the effect.  Nice graphics too.

[Sergioz82]

4 hours ago, Retrospect said:

It's great.  I love the effect.  Nice graphics too.

Thanks

 

About the graphics I recently got my hands on a ZX Spectrum and I noticed how good the programmers worked with the two colors limitation so I tried to replicate some tricks on the TI. For example the black pixels on the wood bars.. it's incredibly simple but effective

Edited March 19, 2023 by Sergioz82

[Retrospect]

5 minutes ago, Sergioz82 said:

Thanks

 

About the graphics I recently got my hands on a ZX Spectrum and I noticed how good the programmers worked with the two colors limitation so I tried to replicate some tricks on the TI. For example the black pixels on the wood bars.. it's incredibly simple but effective

Yeah some great graphics have been done on the Spectrum in spite of it's limitation , the same can, and has, been done for the TI.  There's one thing about the TI that makes things a little more difficult, and that is color is affected by the character sets , ie, Set 5 (64 - 71) can only have 2 colors , the Spectrum has no such limitation that way but then has no Hardware Sprites either. 

[Sergioz82]

Finally I have an update of the game

 

I still haven't got a title, for the moment I call it Will o' wisp.

 

I think I improved the flame trail effect, the previous didn't work well in vertical movement, I use two blue shades and I added some holes in the pattern to make it look more.. flamming.

 

I added a second control mode where the sphere rolls on ground instead of flying. The idea is to use it in narrow passages as shown in the video.

 

I added a status panel (still very temporary) with icons (hold fire to switch abilities)

 

And I added a dynamic map system, the player can go (almost) everywhere.

 

Next step will be adding enemies

 

 

Edited May 12, 2023 by Sergioz82

[sometimes99er]

Ooh. Very nice. 👍
 

[Willsy]

This is looking lovely!

[PeteE]

Fantastic!

[+Ksarul]

I like this so far!

[8_is_enuff]

Very cool. 

[Sergioz82]

Hi, I have a new update for my game 

 

• I finally added enemies. At the moment I made ants, bats and spiders. Ants are harmless and can transport you, but they can also push you out the platform or in a hole. Spiders and bats will damage you (but for now I still have to write the damage routine). At a later time there will be other types of enemies
• I added one of the powers I have in mind: fire element. When the sphere touches a flame (in flight mode), the trail will become red. When this power is on the sphere can burn its way through some elements of the maps like vegetation. The power up is temporary and the duration is indicated by the icon at bottom right of the panel. The map modification is permanent so if the player leaves and then returns in the map all the burnt blocks are removed. I'd like to make this an animated sequence but I don't know how much it is going to stress the processor, so for the moment I take advantage of bitmap mode: when the trail goes through the vegetation it changes the block color to red so.. it's on fire! 
• I implemented a sprite rotation method. This time I tried the reverse system: in even frames the sprites are transferred to VDP from lower to higher while in odd frames it's higher to lower

 

About sprites, the mode is set at magnification 3. The engine can manage 2 sprites enemies and 1 sprite enemies, animated or not animated (1 sprite non animated examples are the moving blocks in the last screen)

 

I have one last big step to make (a third control mode), after that the worst part should be behind.

 

 

 

 

[TheMole]

This looks AMAZING. I love the graphics, and especially the type of gameplay that you're building here. We don't have many of those multi-screen puzzle/platformers on the TI (I can't really come up with any right now, so this might even be a first?) while I think it's a type of the game the platform is extremely well suited for.

 

I hope you make this an epic adventure, with a big number of levels to explore, I could see myself losing a lot of time playing a game like this. As in, playing it for real, not just because it's a cool new game on the TI. I hope I'm conveying how impressed I am :).

 

If I can give up two super small potential improvements for your consideration:

• Consider blanking the VDP output when switching screens, that way you don't see the new screen painting in. Super minor thing, but also dead easy to implement...
• This one is maybe a bit trickier, but when the sphere is not flying, you may want to consider adding some momentum to the controls (so you don't go from a dead stop to full speed and vice versa) by using things like gravity, friction and velocities. I think it may make it feel nicer to play. In my experience, it also makes the jumps feel a bit more natural.

 

Oh, and I also love that this seems to be a completely original idea and not a port of something existing!

 

Again, GREAT work so far, please consider making a boxed cartridge version of this, I'll be first in line to order one ;).

[Sergioz82]

7 hours ago, TheMole said:

This looks AMAZING. I love the graphics, and especially the type of gameplay that you're building here. We don't have many of those multi-screen puzzle/platformers on the TI (I can't really come up with any right now, so this might even be a first?) while I think it's a type of the game the platform is extremely well suited for.

 

I hope you make this an epic adventure, with a big number of levels to explore, I could see myself losing a lot of time playing a game like this. As in, playing it for real, not just because it's a cool new game on the TI. I hope I'm conveying how impressed I am :).

 

If I can give up two super small potential improvements for your consideration:

• Consider blanking the VDP output when switching screens, that way you don't see the new screen painting in. Super minor thing, but also dead easy to implement...
• This one is maybe a bit trickier, but when the sphere is not flying, you may want to consider adding some momentum to the controls (so you don't go from a dead stop to full speed and vice versa) by using things like gravity, friction and velocities. I think it may make it feel nicer to play. In my experience, it also makes the jumps feel a bit more natural.

 

Oh, and I also love that this seems to be a completely original idea and not a port of something existing!

 

Again, GREAT work so far, please consider making a boxed cartridge version of this, I'll be first in line to order one ;).

 

Thank you very very much for your appreciation! I really hope the finished game will hold to expectations

Basically I had this idea of making a ghostly trail in bitmap mode and now the game is taking shape around it. In broad terms I know where I want to go, but things will take a more definite direction during development. 

 

I have in mind 5 levels with a discrete number of maps with alternate routes to take but I'm keeping the level design for the end, my current goal is to complete all the code for a complete run through level 1 (sound excluded). Now that you make think of it I can't recall similar games on TI.. maybe Tutankham?

 

Thanks for the suggestions, I'll disable the screen during map change. About the momentum I like the idea a lot, now I'm going to focus on implementing the 3rd control mode which is a very delicate part and there will be some limitations to overcome but once done I can think of momentum (which I don't know how to do it honestly, I'll have to look around for some ideas)

 

About a boxed version, I'd really love to, however first I have to finish the game

 

[jrhodes]

WOW! Between this, Ghostbusters, and The Legend of Tilda, i'm really excited about the future of TI homebrew.

[TheMole]

9 hours ago, Sergioz82 said:

Now that you make think of it I can't recall similar games on TI.. maybe Tutankham?

 

About the momentum I like the idea a lot, now I'm going to focus on implementing the 3rd control mode which is a very delicate part and there will be some limitations to overcome but once done I can think of momentum (which I don't know how to do it honestly, I'll have to look around for some ideas)

 

Of course, AsmusR put out some awesome Spectrum ports that are definitely multiscreen puzzle platformers (Jet Set Willy comes to mind), but given that Tutankhum was never released back in the day, I would say we didn't have something like this in the old days.

 

The "momentum" based movement is not too hard. The basic principle is that instead of the joystick affecting movement directly, it affects a set of two other variables (usually called velocity). So pressing in a certain direction adds velocity in that direction. At the end of your game loop, you simply add the velocities to the position (capped to a max velocity of course). If no joystick input is received, you reduce the velocites with a certain fixed coefficient (friction).

 

Here's the code from Alex Kidd (in C-like pseudo code):

Spoiler

// Physics defines
#define GRAVITY		 0x040		// Downward acceleration constant
#define ACCEL		 0x050		// Number of subpixels Alex accelerates per frame a directional button is pressed
#define FRIC		 0x030		// Friction when not longer pressing in a certain direction
#define MAX_HSPEED	 0x200		// Max horizontal speed while walking
#define MAX_VSPEED	 0x400		// Max vertical speed

// Starting configuration
player.xpos = 16 << 8;					// x and y position are 16-bit to allow for sub-pixel precision
player.ypos = -132 << 8;
player.vvel = player.hvel = 0;
player.airborne = 0;
player.jumpcounter = MAX_JUMP_COUNT;	// This counter allows us to jump higher by keeping the up direction
										// pressed for longer
// RIGHT pressed
if ( joyst_result & JOYST_RIGHT )
{
	if (player.airborne)
		player.hvel += accel >> 2;		// Player can move less while jumping
	else
	{
		player.hvel += accel;
	}

	if (player.hvel > MAX_HSPEED)
		player.hvel = MAX_HSPEED;
}
// LEFT pressed
else if ( joyst_result & JOYST_LEFT )
{
	if (player.airborne)
		player.hvel -= accel >> 2;
	else
	{
		player.hvel -= accel;
	}

	if (player.hvel < -MAX_HSPEED)
		player.hvel = -MAX_HSPEED;
}
else // No joystick direction pressed, add friction to slow us down
{
	if (!player.airborne)
	{
		// Only add friction when we're on the ground
		if (player.hvel > 0)
			player.hvel -= (player.hvel <  fric) ? player.hvel :  fric;
		else
			player.hvel -= (player.hvel > -fric) ? player.hvel : -fric;
	}
	else
	{
		// No friction when we're airborne
	}
}

// UP pressed, or Joystick button 2
if ( ((joyst_result & JOYST_UP) || (jump_button & JOYST_FIRE)))
{
	if (player.jumpcounter > 0)	
	{
		// jumpcounter will help us have different height jumps
		// as long as the jump button is pressed and the counter is not zero
		// we keep adding vertical velocity
		// (negative because (0, 0) is the UPPPER left hand corner of the screen)
		player.jumpcounter--;
		player.vvel -= (GRAVITY * 1);
		player.airborne = 1;
	}
	else
	{
		player.vvel += GRAVITY;
		if (player.vvel > MAX_VSPEED)
			player.vvel = MAX_VSPEED;
	}
}
else
{
	player.vvel += GRAVITY;
	if (player.vvel > MAX_VSPEED)
		player.vvel = MAX_VSPEED;

	if (!player.airborne)
		// jump button released, reset jump counter back to max
		player.jumpcounter = MAX_JUMP_COUNT; 
	else
		// We're falling, gotta make sure we can't jump mid-air when falling of a cliff
		player.jumpcounter = 0;
}

 

 

[Sergioz82]

3 hours ago, TheMole said:

 

Of course, AsmusR put out some awesome Spectrum ports that are definitely multiscreen puzzle platformers (Jet Set Willy comes to mind), but given that Tutankhum was never released back in the day, I would say we didn't have something like this in the old days.

 

The "momentum" based movement is not too hard. The basic principle is that instead of the joystick affecting movement directly, it affects a set of two other variables (usually called velocity). So pressing in a certain direction adds velocity in that direction. At the end of your game loop, you simply add the velocities to the position (capped to a max velocity of course). If no joystick input is received, you reduce the velocites with a certain fixed coefficient (friction).

 

Here's the code from Alex Kidd (in C-like pseudo code):

  Reveal hidden contents

 

 

// Physics defines
#define GRAVITY		 0x040		// Downward acceleration constant
#define ACCEL		 0x050		// Number of subpixels Alex accelerates per frame a directional button is pressed
#define FRIC		 0x030		// Friction when not longer pressing in a certain direction
#define MAX_HSPEED	 0x200		// Max horizontal speed while walking
#define MAX_VSPEED	 0x400		// Max vertical speed

// Starting configuration
player.xpos = 16 << 8;					// x and y position are 16-bit to allow for sub-pixel precision
player.ypos = -132 << 8;
player.vvel = player.hvel = 0;
player.airborne = 0;
player.jumpcounter = MAX_JUMP_COUNT;	// This counter allows us to jump higher by keeping the up direction
										// pressed for longer
// RIGHT pressed
if ( joyst_result & JOYST_RIGHT )
{
	if (player.airborne)
		player.hvel += accel >> 2;		// Player can move less while jumping
	else
	{
		player.hvel += accel;
	}

	if (player.hvel > MAX_HSPEED)
		player.hvel = MAX_HSPEED;
}
// LEFT pressed
else if ( joyst_result & JOYST_LEFT )
{
	if (player.airborne)
		player.hvel -= accel >> 2;
	else
	{
		player.hvel -= accel;
	}

	if (player.hvel < -MAX_HSPEED)
		player.hvel = -MAX_HSPEED;
}
else // No joystick direction pressed, add friction to slow us down
{
	if (!player.airborne)
	{
		// Only add friction when we're on the ground
		if (player.hvel > 0)
			player.hvel -= (player.hvel <  fric) ? player.hvel :  fric;
		else
			player.hvel -= (player.hvel > -fric) ? player.hvel : -fric;
	}
	else
	{
		// No friction when we're airborne
	}
}

// UP pressed, or Joystick button 2
if ( ((joyst_result & JOYST_UP) || (jump_button & JOYST_FIRE)))
{
	if (player.jumpcounter > 0)	
	{
		// jumpcounter will help us have different height jumps
		// as long as the jump button is pressed and the counter is not zero
		// we keep adding vertical velocity
		// (negative because (0, 0) is the UPPPER left hand corner of the screen)
		player.jumpcounter--;
		player.vvel -= (GRAVITY * 1);
		player.airborne = 1;
	}
	else
	{
		player.vvel += GRAVITY;
		if (player.vvel > MAX_VSPEED)
			player.vvel = MAX_VSPEED;
	}
}
else
{
	player.vvel += GRAVITY;
	if (player.vvel > MAX_VSPEED)
		player.vvel = MAX_VSPEED;

	if (!player.airborne)
		// jump button released, reset jump counter back to max
		player.jumpcounter = MAX_JUMP_COUNT; 
	else
		// We're falling, gotta make sure we can't jump mid-air when falling of a cliff
		player.jumpcounter = 0;
}

 

 

 

Wow, I didn't think that momentum was so fast to implement, good

Thank you very much for the code

[Asmusr]

Your game reminds me of Sorcery, which is a game I always wanted to port to the TI. 

 

[Sergioz82]

13 hours ago, Asmusr said:

Your game reminds me of Sorcery, which is a game I always wanted to port to the TI. 

 

I don't know that game, you mean this one? I watched a video on YT and indeed there is some resemblance in the spooky setting.

 

I can tell my sphere is basically cat's sphere in Wizball, but it was more like an unconscious choice, I realized it in a second moment.

 

 

 

[Asmusr]

7 hours ago, Sergioz82 said:

I don't know that game, you mean this one?

Yes, but I was playing it on the CPC 464.

 

[Retrospect]

The game is reminiscent graphically of some of the games Atlantis were putting out for the C64 / Spectrum / Amstrad, the really nice graphics ones like spooky castle and cavemania.  The wisp thing with the trail, i've not seen done before, and is really a nice touch.  

 

 

[Sergioz82]

15 hours ago, Asmusr said:

Yes, but I was playing it on the CPC 464.

 

Ah yes, now I see more similarities.

[Sergioz82]

14 hours ago, Retrospect said:

The game is reminiscent graphically of some of the games Atlantis were putting out for the C64 / Spectrum / Amstrad, the really nice graphics ones like spooky castle and cavemania.  The wisp thing with the trail, i've not seen done before, and is really a nice touch.  

 

 

 

The very origin of the trail thing is in those trails you see in old VHS cameras of the 80s when a light is in the frame and the camera is not steady. I thought that would be a nice graphic effect to reproduce on a CRT.

 

 I tried the game on real TI + CRT and it looks better than on Emulator+LCD. The trail is thinner because I think random numbers are better on real TI than on emulators, I alredy noticed it with Spac Man where bonuses are more random while on emulators you get mainly boots.

 

Anyway, the first use I found for the idea was to make this ghostly trail, then after the early attempts I started building the game around it.

 

I didn't mention that, but the game I took inspiration from is Abe's Odissey.

 

[+mizapf]

2 hours ago, Sergioz82 said:

The trail is thinner because I think random numbers are better on real TI than on emulators, I alredy noticed it with Spac Man where bonuses are more random while on emulators you get mainly boots.

Not likely because the TI produces pseudo-random numbers only, and those are perfectly emulatable.

[Retrospect]

2 hours ago, Sergioz82 said:

I didn't mention that, but the game I took inspiration from is Abe's Odissey.

Ha, I used to play that a bit of the old Playstation.  Very funny game.  

 

2 hours ago, Sergioz82 said:

I tried the game on real TI + CRT and it looks better than on Emulator+LCD. The trail is thinner because I think random numbers are better on real TI than on emulators, I alredy noticed it with Spac Man where bonuses are more random while on emulators you get mainly boots.

Yeah real CRT's have phospher trails you can't beat old CRTs !