sprite cars in bump n' jump 16x16?!

[8bitwidgets.com]

Hi everyone, so I thought I'd just look at making a car for one of my future game ideas and when i tried to draw one at 8x8 a sprite size i found it pretty limiting.. but then i thought.. huh.. i remember bump n' jump cars having a lot of detail.. 

So I took a screenshot and zoomed in and found the graphics to be 16x16.  Is this being achieved by making 4 gram cards + alternate frames (8 total cards) for each vehicle?  Then each vehicle gets their own 8 cards (player car special treatment because of the multiple colors)

]

 

Then I'm going to go out on a limb here and speculate that while these are cards, there might be a sprite associated with each vehicle for collision purposes set to double size but effectively invisible but still providing collision parameters?  The game never has more than 8 objects on it including the dirt clump..   though how collision is detected for the road edges / water hazards is a whole other system i'm not sure about..  but anyway.  I just realized that eventually i'd really like to have vehicles that are at least 16x16..  or maybe i could get away with 8x16 for many of them.. motorcycle could likely be 8x8 fine.. 

[carlsson]

That is an 8x16 sprite (2 GRAM cards) that is expanded in X direction so each pixel is twice as wide, probably expanded Y direction to 1 so each pixel is as tall as the background graphics are.

 

Remember that MOBs can have X expansion of 1 or 2, and Y expansion of 0.5 (meaning pixels are half as tall as background), 1, 2 or 4, plus that the MOB can be defined as 8x8 or 8x16 actual pixels.

[+DZ-Jay]

That is actually 8 x 16, with double vertical resolution and double horizontal magnification.

 

It takes two cards in GRAM, one for the top portion and one for the bottom portion, so vertically it is 16 pixels.

 

Update: @carlsson beat me to it.  Although I personally prefer to think of the vertical resolution as Single (1/2 pixel height) or Double (1 pixel height), rather than 0.5  vertical magnification.

 

  

Edited September 17, 2021 by DZ-Jay

[carlsson]

Yeah, I suppose it is semantics if you start counting from 1 or 0.5 and whether you relate the size of your MOB pixels to the size of your BACKTAB pixels. To be honest I can't name any other system that has this property, that sprites would support finer resolution than the background graphics.

 

I know that in the 1970's, various racing events in e.g. F1 experimented with bigger sized rear wheels, sometimes even cars with 6 wheels instead of 4 etc. I suppose the graphics in this case are inspired from that. Otherwise the front and rear wheels ought to be the same size.

 

Edit: Well, in drag racing bigger rear wheels may still be the norm but they usually don't want to jump around with those cars.

 

Also I had forgotten about the 8 wheel racing cars!

Edited September 17, 2021 by carlsson

[+DZ-Jay]

19 minutes ago, carlsson said:

Yeah, I suppose it is semantics if you start counting from 1 or 0.5 and whether you relate the size of your MOB pixels to the size of your BACKTAB pixels. To be honest I can't name any other system that has this property, that sprites would support finer resolution than the background graphics.

 

I agree, it’s just semantics.  I just bring it up because it is easier to me to think of it that way, and weird the other way around; and I assumed (perhaps incorrectly) that I would not be the only one.  Heheh.

 

(There is an entire thread where this is argued, rather vigorously.)

 

Quote

I know that in the 1970's, various racing events in e.g. F1 experimented with bigger sized rear wheels, sometimes even cars with 6 wheels instead of 4 etc. I suppose the graphics in this case are inspired from that. Otherwise the front and rear wheels ought to be the same size.

 

I remember the bigger sized rear wheels.  I sort of always imagine F-1 cars like that; but those would be mostly for drag racing.

 

Quote

Edit: Well, in drag racing bigger rear wheels may still be the norm but they usually don't want to jump around with those cars.

 

Oh! Because of Bump N’ Jump, haha! True.

 

(For a moment I thought you meant … well, let’s just say that I was imagining a rather wild track configuration somewhere in the hilliest parts of France!)

 

Quote

Also I had forgotten about the 8 wheel racing cars!

Haha, yeah! Those look like trucks.

Edited September 17, 2021 by DZ-Jay

[carlsson]

Off-topic, but I understand that Ferrari brought out the 8 wheel one as a publicity stunt during off-season to confuse journalists, but never really used it for racing. The above screenshot is from a video game, which I noticed once I watched the video and studied details of the surroundings to figure it was computer generated rather than actual footage. Tyrrell's 6 wheel ones were used in racing though, possibly Ferrari wanted to make a point in how stupid it was by building a 8 wheel one.

 

But yeah, back to Caleb's design it is good to know about the 8x16 sprites and various magnification options. If he has sprites to spend but is ever short of GRAM, he could use a 8x8 one that is magnified in both directions for the rough background, and a 8x16 one that is magnified in one direction for the outline of (vertically) finer resolution. Many C64 games utilized these kind of tricks, putting a 12x21 multi-colour sprite in the back and a 24x21 single colour one for the finer details.

Edited September 17, 2021 by carlsson

[mr_me]

Bumpnjump sprites use default scaling (except for the jump animation).  If you leave the sprite scale parameters set to zero you get half height, high resolution pixels.

 

Edit:

2 hours ago, carlsson said:

To be honest I can't name any other system that has this property, that sprites would support finer resolution than the background graphics.

The Atari 2600 had a horizontal sprite resolution 4x finer than the background.  Vertically they're the same.

 

Can you do this on a C64.  Use high resolution sprites on a low resolution background.  Most C64 games seem to use low resolution backgrounds.

 

Edit 2:

I remember, as a kid, the six wheel F1 car shown in the image above.  They even had remote controlled toys of them.  The dump trucks in Bumpnjump have six wheels.  The tractors look like they have tank treads.

Edited September 17, 2021 by mr_me

[+DZ-Jay]

29 minutes ago, mr_me said:

Bumpnjump sprites use default scaling (except for the jump animation).  If you leave the sprite scale parameters set to zero you get half height, high resolution pixels.

 

Yes.  That’s why to me that is “double vertical resolution.”  Magnifications is still “normal” (0), but the sprite has 16 pixels vertically for twice as much detail than background cards.

 

It’s just a different way of looking at it.  It may help others understand it as well.

29 minutes ago, mr_me said:

Edit:

The Atari 2600 had a horizontal sprite resolution 4x finer than the background.  Vertically they're the same.

 

Can you do this on a C64.  Use high resolution sprites on a low resolution background.  Most C64 games seem to use low resolution backgrounds.

 

[carlsson]

43 minutes ago, mr_me said:

Can you do this on a C64.  Use high resolution sprites on a low resolution background.  Most C64 games seem to use low resolution backgrounds.

Absolutely. Each sprite is individually controlled if it is hires or multicolour, and independent on graphics mode. You can use sprites on top of various text screens (hires, multicolour, extended background colour) or bitmapped screens (hires, multicolour). The reason for the 160x200 resolution was to cram in up to 4 colours per 8x8 block which in practice gets a 4x8 resolution with double width pixels. People using other systems that didn't support multicolour at all usually made fun of the C64's blocky graphics but at the same time would regret the much more colour restricted modes on their own machine, usually only supporting one background and one foreground per character, just like the Intellivision for that matter.

[8bitwidgets.com]

sorry for the slow reply.  i made the mistake of not checking the notification thingy when i posted..  is there a way to mark yourself to follow a post after it's done?  Anywho thanks for the great repliest first of all! 

 

On 9/17/2021 at 9:00 AM, carlsson said:

expanded in X direction

i see, i didn't realize you could double only x or y.. interesting.  but wouldn't that still mean that it's effective eating 2 of the 8 hardware sprites?  

 

I've done some testing and i'm confident that all 8 hardware sprites are used by the player vehicle (3?) and then 4 vehicles + 1 rock dump..  

On 9/17/2021 at 10:10 AM, carlsson said:

could use a 8x8 one that is magnified in both directions for the rough background

what do you mean by this?  is this getting into the backtab (which i think is talking about that idea of baking in "software sprites" as background graphics?  that said i kinda figured using cards / background would be blocky because of the grid the cards have to be in?  I'm just thinking about how smoothly the cars move around and pan across the road.  

 

On 9/17/2021 at 10:10 AM, carlsson said:

C64 games utilized these kind of tricks

so just checking, bump n' jump had mono enemies.  are you saying there might be a way i could have dual color enemies and friendlies?  i would love that, but i'm trying to set my sights what would not require super advanced stuff..  

 

On 9/17/2021 at 10:10 AM, carlsson said:

it is good to know about the 8x16 sprites and various magnification options

still like above, wrapping my head around this.  if these software sprites can be like this, where are the 8 hardware sprites being used?  

 

Are you saying that with the doubling, it's still just the same sprite?  That said I really want rectangular vehicles not square.  The BNJ cars while double high in resolution (as i'm seeing it, maybe wrong) are still square.  

 

 

it just seems too good to be true that i could actually have 8x16 or in my case actually 16x16 but only use half of the 16x16 space to create some approximation like above.  

 

 

 

 

[carlsson]

6 hours ago, Caleb Garner said:

i didn't realize you could double only x or y.. interesting.  but wouldn't that still mean that it's effective eating 2 of the 8 hardware sprites? 

It would be 1 hardware sprite, but with 8x16 resolution it uses 2 GRAM cards. Each sprite can be magnified/expanded X wise times 2 or Y wise times 4 (or 8 if you count the finest resolution to be 1 instead of 0.5).

6 hours ago, Caleb Garner said:

Are you saying that with the doubling, it's still just the same sprite?

Yes, exactly. What I was trying to convey above is that if you have 2 hardware sprites on top of eachother, one might be 8x8 with twice the Y magnification of the other, for a rough single colour layer and then a second 8x16 sprite for a finer detail.

 

Software sprites is another school but could be used if you want even more colours at the expense of slightly more limited movement over other background items.

 

I made a simple example of using two sprites on top of each other. The lower one is 8x8 and magnified vertically X4 while the top one is 8x16 and magnified X2, i.e. same pixel height as background graphics. Of course nothing prevents both sprites to be 8x16 if you need finer resolution also on the background one, it only costs 1 more GRAM.

cars.bas

[+DZ-Jay]

9 hours ago, Caleb Garner said:

sorry for the slow reply.  i made the mistake of not checking the notification thingy when i posted..  is there a way to mark yourself to follow a post after it's done?  Anywho thanks for the great repliest first of all! 

 

i see, i didn't realize you could double only x or y.. interesting.  but wouldn't that still mean that it's effective eating 2 of the 8 hardware sprites?  

 

 

I recommend that you check out the demo "Inty-B Intro" that comes with the IntyBASIC SDK.  In Windows, there is a shortcut to it in the Start Menu when you install the SDK.  On a Mac, you can run it with the following command:

 

intyexec intro

It is a cute little tutorial made by @Tarzilla that shows you the features and capabilities of the Intellivision, including what you can do with sprites.

 

The full code is included in the folder "Documents/Tutorials/Inty-B Intro" and it is written in a way that shows you how to do the same things yourself.

 

 

Quote

so just checking, bump n' jump had mono enemies.  are you saying there might be a way i could have dual color enemies and friendlies?  i would love that, but i'm trying to set my sights what would not require super advanced stuff..  

 

All MOBs are a single color, but by overlaying them, you can make a logical object have multiple colors.  I personally make a distinction between "movable objects" or MOBs (hardware), and "sprites" (logical game objects).

 

In other words, you can make an enemy sprite, say, appear to have three colors by dedicating three MOBs to it, all aligned properly and moving in unison.  It's a single logical sprite, because all three still represent a single enemy.

 

Quote

still like above, wrapping my head around this.  if these software sprites can be like this, where are the 8 hardware sprites being used?  

 

Are you saying that with the doubling, it's still just the same sprite?  That said I really want rectangular vehicles not square.  The BNJ cars while double high in resolution (as i'm seeing it, maybe wrong) are still square.  

 

Just like you can overlay MOBs to add color, you can put them together to make bigger sprites.  Note that doing either of these will use up the MOBs, but sometimes that's what you have to do.

 

If you want to use only one MOB per sprite, and you want it rectangular, you will have to magnify it vertically.  This will make the pixels taller, so it loses resolution.

 

Quote

 

it just seems too good to be true that i could actually have 8x16 or in my case actually 16x16 but only use half of the 16x16 space to create some approximation like above.  

 

 

As stated before, 8x16 sprites are built in.  They use 2 GRAM cards, but by nature are at twice the vertical resolution than the background.  That means that each of the 16 pixels tall, are 1/2 the size of a normal background pixel, so the 8x16 sprite looks 8x8 in size -- as compared to the background.

 

This is a neat feature because it allows you to cram more details into normal-size sprites because of their higher resolution.  (Again, check out the Inty-B tutorial, which illustrates all this in a nice Intellivision program.)

 

So now, if you double it's vertical size, each of those 16 pixels will be the same height as a background card.  It will then appear to be twice as tall as it is wide -- the same as 8x16 background pixels.  That seems to be what you are looking to do.

 

So to make a sprite like that, you need to:

• Define two GRAM cards for it, one for the top half, and one for the bottom half.
• Set it's vertical resolution to "double."
• Set it's vertical size to 2x.

Take a look at the MOB Y Register layout again:

We need to set the YRES bit to 1 (8x16), and the YSIZE field to 01 (full height).

 

   dZ.

Edited September 20, 2021 by DZ-Jay

[Zendocon]

12 hours ago, Caleb Garner said:

sorry for the slow reply.  i made the mistake of not checking the notification thingy when i posted..  is there a way to mark yourself to follow a post after it's done?  Anywho thanks for the great repliest first of all! 

There should be a "follow" button near the bottom of the page, just above the Social Media glyphs.

 

12 hours ago, Caleb Garner said:

i see, i didn't realize you could double only x or y.. interesting.  but wouldn't that still mean that it's effective eating 2 of the 8 hardware sprites?  

Raising the "double resolution" bit just fetches two consecutive cards from GRAM to display as image data, but it's still only one sprite in use.  It's only done vertically to give you an 8x16 image.  It's also not to be confused with doubling the horizontal size or changing the vertical size.

 

12 hours ago, Caleb Garner said:

so just checking, bump n' jump had mono enemies.  are you saying there might be a way i could have dual color enemies and friendlies?  i would love that, but i'm trying to set my sights what would not require super advanced stuff..  

Because sprites can only be one color, having the three colors comprise the player's car (red, white, and black) do in fact use up three of the sprites.

 

12 hours ago, Caleb Garner said:

still like above, wrapping my head around this.  if these software sprites can be like this, where are the 8 hardware sprites being used?

As it is, the 8 sprites are:

• 0-2: player's car
• 3-6: each of the four enemy cars (single color each)
• 7: water hazard sign

12 hours ago, Caleb Garner said:

I've done some testing and i'm confident that all 8 hardware sprites are used by the player vehicle (3?) and then 4 vehicles + 1 rock dump..

Close.  The dump trucks' poops are not sprites; they replace one of the background cards when they're spawned.

[8bitwidgets.com]

13 hours ago, carlsson said:

It would be 1 hardware sprite

ok gotcha really 8 x 16, thanks for the code snippet, you answered my other question which was how would you address it.

 

is there some cost that goes with making all 8 sprites 8x16?  i mean as leans as these systems are with memory, if there is no cost, why not have all sprites be defined as 8x16 with the ability to make them smaller if you need?  who wouldn't want more resolution with every sprite unless there is a tradeoff?  

 

13 hours ago, carlsson said:

Software sprites is another school

right, this is where movement becomes tougher because you have to effectively move within the cards on the screen.  impossible (if not just really difficult) to map out some system that would allow say, a car to move smoothly across the backtab, or maybe i'm totally getting out of my scope of understanding here..  

 

13 hours ago, carlsson said:

I made a simple example of using two sprites on top of each other.

that is awesome and look at me feeling like a legitimate intellivision developer..   compiling .bas files all by myself and running stuff..  =D   but seriously cool

 

13 hours ago, carlsson said:

it only costs 1 more GRAM.

ah ok so this must be the "cost" i was talking about earlier?  No other tradeoffs? like FPS or something?   We get 64 grams at any given time (these 64 grams can be swapped out though throughout the games life when running) so that's pretty sweet consider as we were saying ROM storage space is pretty much a non issue (within reason) these days.  

 

11 hours ago, DZ-Jay said:

"Inty-B Intro"

again feeling the POW-AH!  as i compiled / ran that.. what a fun little intro!  Also checked out a couple others..  lander for example.  very cool.

 

I'm not done replying but gotta head home from work so I'll resume ... TBC! 

 

[+DZ-Jay]

18 hours ago, Caleb Garner said:

ok gotcha really 8 x 16, thanks for the code snippet, you answered my other question which was how would you address it.

 

is there some cost that goes with making all 8 sprites 8x16?  i mean as leans as these systems are with memory, if there is no cost, why not have all sprites be defined as 8x16 with the ability to make them smaller if you need?  who wouldn't want more resolution with every sprite unless there is a tradeoff?

 

Well, there is the fact that they take 2 GRAM cards.  That's 16 for all 8 MOBs if you make them all high-res.  It drops your GRAM budget from 64 to 48, which may or may not be an issue to a programmer.

 

I personally always use 8x16 sprites and avoid magnification like the plague.  I know that those big blocky pixels are a thing, but I don't like them.

 

Quote

right, this is where movement becomes tougher because you have to effectively move within the cards on the screen.  impossible (if not just really difficult) to map out some system that would allow say, a car to move smoothly across the backtab, or maybe i'm totally getting out of my scope of understanding here..  

It's not impossible, but it does require some thought and planning in writing the code for it.

 

Like you suggested, you would have to shift the pixels across multiple contiguous cards in the BACKTAB, which is not trivial.

 

Quote

that is awesome and look at me feeling like a legitimate intellivision developer..   compiling .bas files all by myself and running stuff..  =D   but seriously cool

Cool! 

 

Quote

ah ok so this must be the "cost" i was talking about earlier?  No other tradeoffs? like FPS or something?

Nope, that's it:  the cost is just GRAM.  The STIC (video chip) will handle the display and resolution as normal and you won't notice it.

 

Quote

We get 64 grams at any given time (these 64 grams can be swapped out though throughout the games life when running) so that's pretty sweet consider as we were saying ROM storage space is pretty much a non issue (within reason) these days.  

Right-o!

 

In fact, my game exploits this by dedicating two GRAM cards for each sprite and replacing them on every video frame, as necessary, depending on the animation rate.  So the GRAM is constantly mutating to keep all animations fresh.  It's still very fluid.

 

 

 

Quote

again feeling the POW-AH!  as i compiled / ran that.. what a fun little intro!  Also checked out a couple others..  lander for example.  very cool.

Nice.

 

    -dZ.

 

Edited September 21, 2021 by DZ-Jay

[carlsson]

33 minutes ago, DZ-Jay said:

Well, there is the fact that they take 2 GRAM cards.  That's 16 for all 8 MOBs if you make them all high-res.  It drops your GRAM budget from 64 to 48, which may or may not be an issue to a programmer.

Also remember the word animation. Sure, you can redefine GRAM on vertical blank and all that jazz, but if you're lazy and would want a few frames of animation already into memory and let the sprites change which card to display, having 8 sprites that each take 2 GRAM x perhaps 4 independent animation frames each suddenly makes it 8 x 2 x 4 = 64... and we've used up the entire area. Perhaps that is an extreme worst case scenario though, as often some of the sprites would have the same patterns, just move around independently. For that matter even with regular 8x8 sprites, in my example those would use 32 GRAM unless one redefines it in time for new frames.

[+DZ-Jay]

2 minutes ago, carlsson said:

Also remember the word animation. Sure, you can redefine GRAM on vertical blank and all that jazz, but if you're lazy and would want a few frames of animation already into memory and let the sprites change which card to display, having 8 sprites that each take 2 GRAM x perhaps 4 independent animation frames each suddenly makes it 8 x 2 x 4 = 64... and we've used up the entire area. Perhaps that is an extreme worst case scenario though, as often some of the sprites would have the same patterns, just move around independently. For that matter even with regular 8x8 sprites, in my example those would use 32 GRAM unless one redefines it in time for new frames.

 

Well, that would be an argument in favor of doing it by cycling the GRAM.

 

Still, that cost doesn't come from the actual double-res MOBs, but from the implementation decisions.

 

     -dZ.

[mr_me]

Some Mattel Exec games have lots of frames of animation for sprites, e.g. the running man.  Correct me if I'm wrong but the Exec loads each animation frame into gram as needed, overwriting the previous frame.  So like DZ-Jay says, no more than sixteen gram cards maximum are used for all eight high resolution sprites.

Edited September 20, 2021 by mr_me

[Zendocon]

The running-man animation is 8 frames, so at double-resolution, that's 16 GRAM cards - one quarter of the available GRAM right there.  Fortunately, with most of the Sports Network titles, most if not all of the sprites at any time are the same thing - players.  With clever use of the available characters in the GROM library, you can reduce your GRAM consumption even further.

[carlsson]

FWIW, I still think the importance of the graphics symbols in GROM is overrated. Yes, there are lines for certain types of drawings but you really would need to center your graphics around what's available, rather than the opposite. A while ago when Chris was toying with a Tempest game that would consume a lot of GRAM for the various lines, I drew a design using 22 GRAM of which perhaps 8 exist in GROM. Yeah, that is 36% of the requirements but then again Tempest is very heavily based on wireframe so it should be suitable for generic symbols.

 

Perhaps a side scrolling Scramble type of game has use of the GROM too.

Edited September 21, 2021 by carlsson

[+DZ-Jay]

50 minutes ago, Zendocon said:

The running-man animation is 8 frames, so at double-resolution, that's 16 GRAM cards - one quarter of the available GRAM right there.  Fortunately, with most of the Sports Network titles, most if not all of the sprites at any time are the same thing - players.  With clever use of the available characters in the GROM library, you can reduce your GRAM consumption even further.

The question was whether the EXEC loads all those 16 GRAM cards at once and increases the pointer in the MOB’s A register, or does it just update the 2 GRAM cards for the MOB whenever the animation advances a frame?

 

I believe the EXEC supports both kinds of animation, but I am not sure.

 

   dZ.

Edited September 21, 2021 by DZ-Jay

[+DZ-Jay]

35 minutes ago, carlsson said:

FWIW, I still think the importance of the graphics symbols in GROM is overrated

That’s because you have not used them.

 

For those who have, those lines and blocks can fill the edges of rather complex contours of more sophisticated graphics.

 

You think geometric shapes = programmer art; but it’s not just that.

 

Quote

Yes, there are lines for certain types of drawings but you really would need to center your graphics around what's available, rather than the opposite.

Actually, quite the opposite.  I first design graphics with custom cards, then I see which ones match closely to those in GROM and try to swap them.  I also try to shift the pixels and align to the card boundaries to reuse cards as much as possible, while still giving a seamless and organic look.

 

I do this until I reduce the GRAM count to a practical level.

 

It’s not perfect, and there are plenty of other restrictions, but I categorically disagree with those who reject this off-hand with some assumption that one mode is “superior” to the other.

 

They both have compromises, and they both have strengths, and they both can support very creative works in their own way.

 

Quote

A while ago when Chris was toying with a Tempest game that would consume a lot of GRAM for the various lines, I drew a design using 22 GRAM of which perhaps 8 exist in GROM. Yeah, that is 36% of the requirements but then again Tempest is very heavily based on wireframe so it should be suitable for generic symbols.

 

Take a look at an old thread where I was helping @artrag compose a 3-D looking title screen for Deep Zone.

 

I never completed the work due to other priorities, but I got rather far, and what I came up with at the time was good, and was only possible in Color Stack mode using GROM cards.

 

I still have confidence that I would have been able to reduce the card count to fit in GRAM by abusing the GROM even more and aligning the edges further to card boundaries.

 

For other examples, dig up all the screenshots from GroovyBee’s announced but unreleased games.  His pixel artist used Color Stack extensively in very impressive and colorful screens.  No lines-and-patterns programmer art there, yet they use GROM.
 

 

Quote

Perhaps a side scrolling Scramble type of game has use of the GROM too.

 

Perhaps.

Edited September 21, 2021 by DZ-Jay

[8bitwidgets.com]

16 hours ago, DZ-Jay said:

avoid magnification like the plague

yea i would as well, i don't see it bringing any help to my ideas at this time, but i do see how it might be helpful.  For example if I wasn't doing a backtab for the Tanker.. it would certainly be helpful to have a vertically longer sprite for it, though it would look less than ideal at least it would have the appearance of taking up the kind of space an 18 wheeler would compared to a regular car and only be one sprite.  

 

16 hours ago, DZ-Jay said:

contiguous cards in the BACKTAB, which is not trivial.

OK so I'm at least following how that would work in principle.  For RD I will not do that.  I could see it being really hairy and ultimately giving less than ideal results for the effort.  

 

16 hours ago, DZ-Jay said:

Nope, that's it:  the cost is just GRAM

That's a fair tradeoff for sure

 

17 hours ago, DZ-Jay said:

It's still very fluid.

that is an amazing cut scene!  we needed you and the others making games back in 1980! =D 

16 hours ago, mr_me said:

animation for sprites, e.g. the running man.

I'm surprised the running man wasn't in GROM seeing how common it was used in many mattel games.  

 

16 hours ago, DZ-Jay said:

cycling the GRAM

I definitely see that being in my future but not for awhile!

 

 

[+DZ-Jay]

33 minutes ago, Caleb Garner said:

yea i would as well, i don't see it bringing any help to my ideas at this time, but i do see how it might be helpful.  For example if I wasn't doing a backtab for the Tanker.. it would certainly be helpful to have a vertically longer sprite for it, though it would look less than ideal at least it would have the appearance of taking up the kind of space an 18 wheeler would compared to a regular car and only be one sprite.  

 

Yes, if there is no other way to do so, I would consider it as well.  The requirement in that case is to make the sprite large enough, which trumps it’s resolution.

 

Quote

OK so I'm at least following how that would work in principle.  For RD I will not do that.  I could see it being really hairy and ultimately giving less than ideal results for the effort.  

 

Actually, it can be very effective, although you do not get 8x16 hi-res sprites with background/software sprites.

 

Quote

That's a fair tradeoff for sure

It is, if your game requires that many sprites.  Another trade-off could be to reduce the number of objects and adjust the mechanics.

 

I know of at least one game in which style and graphical detail were chosen over number of enemies, and it didn’t seem to have suffered much in the conversion.

 

Quote

that is an amazing cut scene!  we needed you and the others making games back in 1980! =D 

Thanks.

 

Quote

I'm surprised the running man wasn't in GROM seeing how common it was used in many mattel games.  

 

Probably because it is not generic enough.  It was used quite a lot because the animation was so good, but it wouldn’t apply to all games.

 

Also note that there are slight variations in some of the running men of various games.

 

Quote

I definitely see that being in my future but not for awhile!

One step at a time.

Edited September 21, 2021 by DZ-Jay

[carlsson]

In case you have use of it, here is a simple example that cycles between four different frames. This one only updates 2 cards at a time but as you know, IntyBASIC usually can squeeze in up to 16 in a call. Also note the introduction of a signed variable to enable values below 0, in case you didn't see/use those before.

 

cars2.bas