Game port idea - Gridrunner by Jeff Minter (possibly even for mini-memory)

[palmheads]

Hey

 

Just putting an idea out there.

 

Found this interesting piece of the history of the classic game Gridrunner by Jeff Minter & Llamasoft

 

http://www.minotaurproject.co.uk/grr_hist_gr.php

 

One interesting titbit was the original (& best for the 8 bitters anyway) Vic 20 version was done for the unexpanded Vic (so 3.5k).

 

That would make it possible to squeeze into the mini-memory's available ram (about 4k)

 

Been playing it on my android phone (they have done an android version)

 

http://www.minotaurproject.co.uk/Minotaur/donate.php(see 'Here is Gridrunner for Android').

 

Its an awesome game, really enjoyable to play. Gonna try the Vic 20 version using VICE. Here are all the versions for 8 bitters Llamasoft has made available for download

http://minotaurproject.co.uk/lc-8bit.php

 

 

cheers

Daryn

 

[+mizapf]

Matrix please!

 

And somebody please port Attack of the Mutant Camels. Can't be that difficult.

[carlsson]

Side note regarding Attack of the Mutant Camels: If you're from the USA, this game is equivalent with Gridrunner or Matrix, but if you're from Europe, this game is a clone of Empire Strikes Back. Since your location is Germany, I suppose you mean the latter game.

[+mizapf]

Yes, I just read about that confusion in Wikipedia. I referred to the game that remotely resembles the fight against the AT-AT in the Star Wars V movie.

 

 

Discuss: Is this feasible on the TI? This was the very first game a friend showed me who had just bought a new C64, back in 1983.

Edited July 28, 2015 by mizapf

[Bill Loguidice]

Yes, I just read about that confusion in Wikipedia. I referred to the game that remotely resembles the fight against the AT-AT in the Star Wars V movie.

 

 

Discuss: Is this feasible on the TI? This was the very first game a friend showed me who had just bought a new C64, back in 1983.

 

There's no reason it wouldn't be feasible on the TI-99/4a. The ColecoVision got a good homebrew port recently called "Battle of Hoth."

[+mizapf]

Some points to remark:

• Stars do not move and they do not mix with the landscape below; easy.
• No soft scrolling, looks like column scolling, also easy.
• The camel is pretty big. When implemented by big sprites, we would need compose several of them
• The ship could be done with two sprites with changing colors
• Anybody else who misses a proper gray color?
• Shooting: Most likely by a fast sprite; painting a single line (Parsec style) could be possible, but we'd have to do a lot of extra work
• The shots from the camel are sprites (are we already at 5 per line?)
• Well, sound would be different, but I don't have any experience in "sound engineering"

[am1933]

Ughhhhhhhhh, terrible, just horrible, I'm going to be sick-some folk are posting pics/clips of the awful C64 version of Mutant Camels, we all know the Atari 8bit version pisses all over it

 

https://www.youtube.com/watch?v=SxigL7CX8qI

 

Watch and learn kiddies!!!!!

[Bill Loguidice]

Ughhhhhhhhh, terrible, just horrible, I'm going to be sick-some folk are posting pics/clips of the awful C64 version of Mutant Camels, we all know the Atari 8bit version pisses all over it

 

https://www.youtube.com/watch?v=SxigL7CX8qI

 

Watch and learn kiddies!!!!!

 

Each version has their pluses and minuses, and neither version, particularly the early C-64 release, does much to show off the hardware capabilities. It's arguable that it's actually a worse game than its inspiration/what it tried to copy, the Parker Brothers Atari 2600 release of Empire Strikes Back.

 

EDIT: Here's a link to what it *could* have looked like on the C-64 with proper graphic design and the programming experience from just a few years later could have made: http://www.gamesthatwerent.com/gtw64/empire-strikes-back/

Edited July 28, 2015 by Bill Loguidice

[+mizapf]

Indeed, looks pretty good on Atari! But even farther out of reach.

[+mizapf]

As always, we're fantasizing about games of other platforms for a while, and once this threads drops into oblivion (aka next page), nobody remembers.

 

I just set up a page on ninerpedia called "Challenges"; have a look: http://www.ninerpedia.org/index.php/Challenges

 

You are of course invited to add more. Hopefully this will help us pursuit our dreams with some more persistence. :-)

[Wildstar]

 

Some points to remark:

• Stars do not move and they do not mix with the landscape below; easy.
• No soft scrolling, looks like column scolling, also easy.
• The camel is pretty big. When implemented by big sprites, we would need compose several of them
• The ship could be done with two sprites with changing colors
• Anybody else who misses a proper gray color?
• Shooting: Most likely by a fast sprite; painting a single line (Parsec style) could be possible, but we'd have to do a lot of extra work
• The shots from the camel are sprites (are we already at 5 per line?)
• Well, sound would be different, but I don't have any experience in "sound engineering"

 

 

Yep,

 

The sprite for the camel looks like maybe built from 5-6 VIC-II sprites but I have to look at the video a few times to discern if its 5-6 sprites not 3 sprites using Double Height and/or Double width. It could be two sprites with changing sprite data to reflect movement of the camel's feet and neck. It seems to me that they would likely be using double wide/double height and 3 sprites on screen as they will probably have close to 3-4 sets of sprite data for the movement and then just cycle the color around on the sprite register.

 

Due to the different sprite size, a more complex sprite arrangement maybe needed to be done. Probably close to 5-6 sprites.

 

The ship is one sprite on-screen but you may need two sprite bitmap sets. One for its flight the one direction and the other being a flipped mirror image. Otherwise one sprite data can be used but a flip routine can be used.

 

The number of sprites can then be tricked using a more sophisticated approach.... sprite multiplexing.

 

F18A will do this fabulously. TI-99/4A will have more challenges.

 

So you can do 'software sprites' if necessary.

 

The c64's VIC-II had 8 sprites on a single line. It would be easier for the C= but I believe TI-99/4A was limited to what was it....4 per scanline. Trying to get more than 4 on the line without flickering sprites is going to be a challenge.

 

Stock VDP will require sprite multiplexing. Is this trick common on the TI-99/4A?

 

The best current solution for this is with the F18A VDP upgrade.

[Asmusr]

Stock VDP will require sprite multiplexing. Is this trick common on the TI-99/4A?

 

I guess this is what we call a flicker algorithm - that you cycle between which of the displayed sprites get the highest priorities in different VDP frames? I have used it in most of my games (which makes it common now ) but I don't think it was common on the TI back in the days.

[+mizapf]

The best current solution for this is with the F18A VDP upgrade.

 

This is what I am most afraid of. You can possibly do it with the F18A. But in my opinion this will be the ultimate defeat. It will become the proof that the TI-99/4A was definitely too bad to do it.

 

I could also imagine to achieve a lot more with my Geneve's 9938, but this not a solution either.

[Asmusr]

The camel can be made with 3x2 magnified sprites. The size is exactly 96x64 pixels.

 

[Wildstar]

That would work. I just couldn't recall the magnified sprites capability. Thanks Asmusr-M.

 

One sprite can be 16x16 pixels but you can use magnification for double-width and height pixels which is 32 x 32 px.

 

Therefore 3 sprites across. Then you have the jet and the pulsed lasers and energy ball. This can mean, you could potentially have up to 6 sprites on the same raster line. This would put us 2 hardware sprites over the hardware sprite limits. So my suggestion is using "software sprites" for the extra sprites over the limit but we can reduce the number of sprites needed for the camel. After all the TI-99/4A screen is 256x192 pixels and we don't have borders like the C64. 2x2 sprites can be used to make up the camel. This rough size of the sprite on a TV screen will be about the same size as on the C64 in connection with a screen of the same size.

 

The fighter jet's laser can be a software sprite because they don't have to actually involve sprite collision. They can involve simply knowing where the fighter jet is on the screen which means a little bit of math logic. You need to know is position of four coordinates of the camel sprites. Then you simply need to now what raster line and direction the jet is. Then when fire button event trigger is activated, then you need to count points of hits (raising the score counter) because you know the laser would hit the object. It isn't like the camel is going to dodge projectiles at supersonic or speed of light. You just need to be sure the scanline of the jet's laser cannon... which can be sort of arbitrary along the height of the jet. Say the jet is 8 pixels high and centered then laser being 4 scanline pixels down from the top-left corner of the sprite. Just figure it out there. A little of math logic, you can calculate along the 2d matrix the position of the laser cannon (scan line position and if it is between the top and bottom of the camel sprites then it is a hit if the jet is facing the camel.

 

That would be the other math logic to employ.

 

The camel would be two sprites x two sprites. This would mean only two sprites of the camel will ever be on the same scan line. Therefore, the camel would only occupy 2 of the 4 sprites per scanlines.

 

The fighter jet would be a hardware sprite. The third sprite in your sprite per scan line limit. Then you will have one more hardware sprite.

 

The camel's weapon. This would be a hardware sprite.

 

Make the camel out of four 16x16 pixels sprites in magnification mode.

 

The fighter jet's laser doesn't need to be a sprite of its own. In fact, you can probably just use the same fighter jet sprite and just briefly add a few pixels to depict firing. This would require the sprite itself to be in multicolor bitmap mode so you can have the additional colors to depict the firing of the weapon. I don't know if it is possible on the TI-99/4A to be in hires bitmap mode and have the sprite in multicolor mode while the other sprites maybe in hires. So it will be interesting. I know it can be done on the C64 but not sure with TI.

 

What I seen with Flappy Bird for TI-99/4A... it might be possible. It won't be easy but we would be pushing the TI-99/4A stock VDP a bit.

[Asmusr]

The fighter jet's laser doesn't need to be a sprite of its own. In fact, you can probably just use the same fighter jet sprite and just briefly add a few pixels to depict firing. This would require the sprite itself to be in multicolor bitmap mode so you can have the additional colors to depict the firing of the weapon. I don't know if it is possible on the TI-99/4A to be in hires bitmap mode and have the sprite in multicolor mode while the other sprites maybe in hires. So it will be interesting. I know it can be done on the C64 but not sure with TI.

 

We don't have multicolor sprites on the TI. To display additional colors we need to stack sprites.

[Wildstar]

 

We don't have multicolor sprites on the TI. To display additional colors we need to stack sprites.

 

ok... so that will make things a little tricky. That won't work for us exactly... UNLESS we can find some way to do an "FLI" effect on the sprite.

 

How many colors within a sprite per 9918A specifications. If we can do an FLI-like effect within the sprite itself, this could give us more colors per sprite. This would be tricky.

 

Since the fighter jet is flickering even in the C64 game then we can use it to our effect. Say the jet is blue but flickers to white when our laser weapon is fired and a smidged hint of the weapon firing can be employed in the sprite bitmap like the muzzle blast from a machine gun. We do something graphically.

 

Just a thought and we just eliminate the need to have some sort of multicolor sprite.

Edited August 1, 2015 by Wildstar

[Tursi]

1 color per sprite.

 

But why not draw the camel with background characters? It's big and blocky, and it comparably doesn't move very often. (And still small enough to draw every frame for the scrolling).

[ti99iuc]

I referred to the game that remotely resembles the fight against the AT-AT in the Star Wars V movie.

 

Discuss: Is this feasible on the TI? This was the very first game a friend showed me who had just bought a new C64, back in 1983.

Hello guys,

i remembered i had a similar game in Assembler for TI99 so i loocked again the .dsk

 

 

 

 

it is written in EA3, no sounds and no title screen or credits so i do not know much of this game... maybe it is a beta-game ?

note also the spaceship very similar to the Parsec's one.

anyway our friend BuddyBear selling this on ebay

 

 

i shared for the download << Here >>

Edited August 2, 2015 by ti99iuc

[Wildstar]

1 color per sprite.

 

But why not draw the camel with background characters? It's big and blocky, and it comparably doesn't move very often. (And still small enough to draw every frame for the scrolling).

 

Could work if the mountains are not scrolling right behind the camel but is say... above the camel per se. Then you move the camel like character smooth scroller. The camel pixels would be foreground pixel and the background pixels would be the background. Use raster interrupt to change the background color as needed when it needs to be.

 

Mode 2 would be our best bet but if I were being more ideal. I would have the mountains and star background above the camel versus so we keep from exceeding 2 colors per 8x1 pixels. If there is however a so called universal background color aside from the character background color... I would find that to be something interesting. I'm curious about hybrid modes but key is not to have uncontrolled graphic glitches.

[+mizapf]

Use raster interrupt to change the background color as needed when it needs to be.

 

No such interrupt on the 9918, unfortunately. We only have a full-frame interrupt; only the v9938 offers a raster line interupt.

[Wildstar]

 

No such interrupt on the 9918, unfortunately. We only have a full-frame interrupt; only the v9938 offers a raster line interupt.

 

I don't remember all the registers the 9918 had to be certain. Anyway, raster interrupt may or may not be necessary but it would have been really really nice. So the other trick is using other timing events to line things up so it would be really hard to do things like raster bars for example... in a decent manner.

 

Otherwise, we have to change the background color per character or 8x1 pixel area if we use certain modes. We just have to avoid more than 2 colors per 8x1 pixel area.

Edited August 2, 2015 by Wildstar

[+mizapf]

The sad thing is, while we have a proper video processor in the TI-99/4A, unlike the C64 with a simpler video controller, we paid it with some crucial features. The private memory together with the missing RL interrupt makes it arguably difficult to achieve comparable results.

 

Still, I'm pretty sure we'll come to a good solution. The recent game developments, particular by Rasmus, showed that we stopped much too early.

[sometimes99er]

Found this interesting piece of the history of the classic game Gridrunner by Jeff Minter & Llamasoft

 

One interesting titbit was the original (& best for the 8 bitters anyway) Vic 20 version was done for the unexpanded Vic (so 3.5k).

 

That would make it possible to squeeze into the mini-memory's available ram (about 4k)

 

Been playing it on my android phone (they have done an android version)

 

Its an awesome game, really enjoyable to play. Gonna try the Vic 20 version using VICE.

Did you get around to playing the Vic version ?

 

The Android version has it's share of "action" going on there.

 

 

After a taste of that, the Vic version might appear a bit "dull", but certainly, a comparable version is plausible on a comparable TI system.

 

[palmheads]

Did you get around to playing the Vic version ?

 

The Android version has it's share of "action" going on there.

 

 

After a taste of that, the Vic version might appear a bit "dull", but certainly, a comparable version is plausible on a comparable TI system.

 

 

The Android version is pretty damn cool allright!

 

Yip, had a go at the VIC 20 version, still quite impressive. Pretty cool game I reckon.

 

cheers

Daryn