Magnavox Odyssey 2: 64 Shapes?

[johannesmutlu]

1 hour ago, DanBoris said:

 

The animated frog on the intro screen is easy, that's just a combination of the four sprites. The bigger question is, how were the cars done?

Seriously,somebody on youtube have to come up with a video and explain what’s graphically possible and what not and he should also come up with a toturial at how to create your own sprites and BG tile trough the combinations of those 64 availible tile sets,

i created my mockup screen of donkeykong with those availible tile sets by using pixelcut app to allow me fotoshop stuff by flipping or copy pasting and combining stuff with (or over) each other just to get an idea at how a donkeykong game should in theory look like on the odyssey 2 (depending on it’s restrictions),now if only we could create a mario sprite by using the snanline trick,that would be great,and since there were already 3 donkeykong 1 games (including 1 homebrew version of it) on the C64,it would be fair to see an homebrew port of donkeykong on the odyssey 2,let it courage and spark ideas to homebrewers to try it because it’s time,

same thing with pac man,there are already dozens of pac man games (official and unofficial ones) on that atari 7800 but theres still no odyssey 2 version of pacman,well it’s time to change that,so come on over homevrewers were are you waiting for🤣

Edited February 1 by johannesmutlu

[DanBoris]

I look a look at Frogger and I think the cars and logs are combinations of characters and sprite with mid screen changes to re-use the sprites. I also forgot that there is a way to display only portions of the internal characters (with some limitations) which allows for some more flexibility in creating custom images. 

[DanBoris]

Here is what the highway part of the game looks like if you turn off all the sprites.

 

 

And here it is with the sprites on..

 

[johannesmutlu]

On 2/2/2024 at 12:36 AM, DanBoris said:

I look a look at Frogger and I think the cars and logs are combinations of characters and sprite with mid screen changes to re-use the sprites. I also forgot that there is a way to display only portions of the internal characters (with some limitations) which allows for some more flexibility in creating custom images. 

Interesting,if it is true, that’s that portions of each bg character set can be displayed by using the scan line trick,sothat even if those bg tile sets are not allowed to be overlapped on top of each other,we still might could just create all kinds of shapes that way,

so if we take for example tile 2F wich is a square tile,we could view different portions of that block per scan line and per different positions of each block (thus basically turning on or off each pixel from that tile block)we could create all kinds of shaped albeit somewhat monochrome,but it’s better then nothing i suppose as it could give us atleast more freedom to create what we want,even if the cou isn’t up to the task,an external power powerful cpu could take over the main cpu and do all that dirtt task😁

but now on,it’s just a theory,if only a homebrewer will stand up and port certain games to if wich makes use of this scan line trick to create all kinds of shapes with it,would be great.

[DanBoris]

2 hours ago, johannesmutlu said:

Interesting,if it is true, that’s that portions of each bg character set can be displayed by using the scan line trick,sothat even if those bg tile sets are not allowed to be overlapped on top of each other,we still might could just create all kinds of shapes that way,

so if we take for example tile 2F wich is a square tile,we could view different portions of that block per scan line and per different positions of each block (thus basically turning on or off each pixel from that tile block)we could create all kinds of shaped albeit somewhat monochrome,but it’s better then nothing i suppose as it could give us atleast more freedom to create what we want,even if the cou isn’t up to the task,an external power powerful cpu could take over the main cpu and do all that dirtt task😁

but now on,it’s just a theory,if only a homebrewer will stand up and port certain games to if wich makes use of this scan line trick to create all kinds of shapes with it,would be great.

 

You might be able to change the image from scanline to scanline, but it's unlikely you could change it on a single line. The hardware probably works by loading the bit pattern for each character line into a shift register which is then shifted out into the video signal. If that is the case then once the character has started to be drawn you wouldn't be able to change it. 

[johannesmutlu]

3 hours ago, DanBoris said:

but it's unlikely you could change it on a single line. The hardware probably works by loading the bit pattern for each character line into a shift register which is then shifted out into the video signal. If that is the case then once the character has started to be drawn you wouldn't be able to change it.

If that’s the case with a background,then we might could try do such trick with sprites (since sprites are allowed to be overlapped over each other) and emulate a background with it with desired shapes,by alternating trough different sprites per frame in order to virtually fill up the screen,since the 

O2 could only view 4x 8 by 8 sprites atonce,it may result in huge flicker it should give us hopefully more freedom that way,right?

 

[DanBoris]

1 hour ago, johannesmutlu said:

If that’s the case with a background,then we might could try do such trick with sprites (since sprites are allowed to be overlapped over each other) and emulate a background with it with desired shapes,by alternating trough different sprites per frame in order to virtually fill up the screen,since the 

O2 could only view 4x 8 by 8 sprites atonce,it may result in huge flicker it should give us hopefully more freedom that way,right?

 

 

I really need to get my O2 development system set back up so I can test some of these ideas.

[johannesmutlu]

37 minutes ago, DanBoris said:

 

I really need to get my O2 development system set back up so I can test some of these ideas.

Can’t wait to hear about those end results some day👍

Edited February 13 by johannesmutlu

[DanBoris]

On 2/12/2024 at 7:59 PM, johannesmutlu said:

Can’t wait to hear about those end results some day👍

 

I did verify on the actual hardware that if two characters overlap, even overlapping blank pixels, you get strange results. Here is a picture of what happens when I try to put two character 27s right next to each other. You can see one on the left but the other becomes garbage.

 

[johannesmutlu]

12 hours ago, DanBoris said:

 

I did verify on the actual hardware that if two characters overlap, even overlapping blank pixels, you get strange results. Here is a picture of what happens when I try to put two character 27s right next to each other. You can see one on the left but the other becomes garbage.

 

That’s an interesting thing to know,so basically the O2 is just a dead horse to do interesting things with it right? So you cannot costumize your own sprites right?,theres no way to avoid using those characters on the O2 for sprites?

Anyway,wikipedia mentions the following things

 

12 hours ago, DanBoris said:

 

• 4 8×8 single-color user-defined sprites; each sprite's color may be set independently
• 12 8×8 single-color characters; must be one of the 64 shapes built into the ROM BIOS; can be freely positioned like sprites, but cannot overlap each other; each character's color may be set independently
• 4 quad characters; groups of four characters displayed in a row
• 9×8 background grid; dots, lines, or solid blocks

 

so it says that 4 8x8 sprites are definible by the user does it mean that the user could create their own sprites without having to rely on it’s internal 64 character set???

 

it also says 12 8x8 chraracters in single color wich must be one of those 64   shapes inside that bios as well as being able to stack 4 quad characters next to each on a row,

 It also talks about 8x8 background grid,dots,lines,solid blocks etc,,,

wich makes me wonder are characters and sprites the same thing or is it something different from each other in this case???

if sprites and characters means the same thing,then i conclude that the O2 is technically just a dead on a rival system with no way of doing famcy tricks to get around those graphical restrictions but who knows,

anyway thanks alot for testing this out now i know the hard truth about the O2 in wich in my opinion shouldn’t,ve be that restrictive,wich is a huge shame,now if it was just an exercising game developing program (for whether system) to let users learn how to make their own games,or if it is a console with builtin games, then i can respect and accept that such limited 64 character set inside it,but why making a cartride based ‘hybrid’ console with such graphical restrictions to not allow programmers costumize their own graphics, is just waaay beyond me,even the not less powerful channel f from 1976 wich came 2 years earlier then the O2,did gave you more freedom,

But still,am curious about whether sprites/characters are costumizible on the O2 or if they have to rely on the same 64 tile sets from the O2,

but again thanks alot for testing it out,i definitely appreciate that👍 

 

 

[DanBoris]

1 hour ago, johannesmutlu said:

 

so it says that 4 8x8 sprites are definible by the user does it mean that the user could create their own sprites without having to rely on it’s internal 64 character set???

 

it also says 12 8x8 chraracters in single color wich must be one of those 64   shapes inside that bios as well as being able to stack 4 quad characters next to each on a row,

 It also talks about 8x8 background grid,dots,lines,solid blocks etc,,,

wich makes me wonder are characters and sprites the same thing or is it something different from each other in this case???

if sprites and characters means the same thing,then i conclude that the O2 is technically just a dead on a rival system with no way of doing famcy tricks to get around those graphical restrictions but who knows,

anyway thanks alot for testing this out now i know the hard truth about the O2 in wich in my opinion shouldn’t,ve be that restrictive,wich is a huge shame,now if it was just an exercising game developing program (for whether system) to let users learn how to make their own games,or if it is a console with builtin games, then i can respect and accept that such limited 64 character set inside it,but why making a cartride based ‘hybrid’ console with such graphical restrictions to not allow programmers costumize their own graphics, is just waaay beyond me,even the not less powerful channel f from 1976 wich came 2 years earlier then the O2,did gave you more freedom,

But still,am curious about whether sprites/characters are costumizible on the O2 or if they have to rely on the same 64 tile sets from the O2,

but again thanks alot for testing it out,i definitely appreciate that👍 

 

 

 

Sprite and characters are different things. Sprites have a user definable shape and can overlap any other object on the screen, sprite of characters. Characters have to come from the internal character set and can not overlap other characters. The O2 clearly wasn't "dead on arrival" since it has a good sized library of decent games. It was not as flexible as the 2600 but the programmers managed to do some cool stuff with the hardware. The Channel F did have more flexible graphics, but it O2 had a higher resolution and a little more color flexibility. The Channel F also has a pure bit-mapped display so the CPU had to do all the drawing work which would have made if difficult to go more complex arcade style games like the O2 did. 

 

[johannesmutlu]

26 minutes ago, DanBoris said:

 

Sprite and characters are different things. Sprites have a user definable shape and can overlap any other object on the screen, sprite of characters. Characters have to come from the internal character set and can not overlap other characters. The O2 clearly wasn't "dead on arrival" since it has a good sized library of decent games. It was not as flexible as the 2600 but the programmers managed to do some cool stuff with the hardware. The Channel F did have more flexible graphics, but it O2 had a higher resolution and a little more color flexibility. The Channel F also has a pure bit-mapped display so the CPU had to do all the drawing work which would have made if difficult to go more complex arcade style games like the O2 did. 

 

WooooW so sprites can be created by the user in whether shape or form without having to rely on it’s internal 64 character set?

well that’s a great thing to know,and with that in mind i was thinking we may could rely on sprites alone instead to make a user definible fake a background that way by alternating between each sprites per frame,so if we want we could make a fame user definible background and spliting it into sections of 4 8x8 sprites and alternate between each per frame,so frame 1 such view the first 4 8x8 sprites,frame 2 those second 8x8 sprites,frame 3 should view those other 4 8x8 sprites and so forth and so forth,sothat in theory you could view 240 sprites atonce  to able to fake an user definible background,sure it may will result in tons of flicker and slowdown and it may will require extra ram,rom along with bankswitching and an extra external processsor to do such stuff,but i think it’s a way to somewhat get around these graphical limitations,and with that in mind,i cannot wait to see a proper donkeykong,pac man and improved popeye port to the O2,being graphically close to the arcade versions of it,

so who knows what homebrewers could pump out of the O2 with these tricks,

By the way about the channel f,did you have seen those homebrew ports of pac man and tetris on it? They are AMEZING,they graphically and sounds close to the arcade versions of it,

again thanks for mentioning these stuff😁

[Kurt_Woloch]

14 hours ago, johannesmutlu said:

WooooW so sprites can be created by the user in whether shape or form without having to rely on it’s internal 64 character set?

well that’s a great thing to know,and with that in mind i was thinking we may could rely on sprites alone instead to make a user definible fake a background that way by alternating between each sprites per frame,so if we want we could make a fame user definible background and spliting it into sections of 4 8x8 sprites and alternate between each per frame,so frame 1 such view the first 4 8x8 sprites,frame 2 those second 8x8 sprites,frame 3 should view those other 4 8x8 sprites and so forth and so forth,sothat in theory you could view 240 sprites atonce  to able to fake an user definible background,sure it may will result in tons of flicker and slowdown and it may will require extra ram,rom along with bankswitching and an extra external processsor to do such stuff,but i think it’s a way to somewhat get around these graphical limitations,and with that in mind,i cannot wait to see a proper donkeykong,pac man and improved popeye port to the O2,being graphically close to the arcade versions of it,

so who knows what homebrewers could pump out of the O2 with these tricks,

By the way about the channel f,did you have seen those homebrew ports of pac man and tetris on it? They are AMEZING,they graphically and sounds close to the arcade versions of it,

again thanks for mentioning these stuff😁

Yes, they can be created. The problem is bandwidth limitations, so things might get tricky. Actually, I first deemed it impossible, but the more I think about it, I figure it might just work out.

Anyway, the shapes of the sprites are stored in the VDC, so to change the shape of a sprite you have to send the new shape to the VDC, every byte of it. But they are shown on consecutive scanlines, and each scanline is doubled, so in average you have 2 scanlines to write 4 bytes of sprite shapes plus rewrite the registers so that the sprites get displayed again further down the screen once they are done. The question is if this works while they are being displayed or if the VDC has some restrictions preventing this. Also, you'd probably have to do the register re-writes all at once so there's no gap between the last scanline of a sprite and the first scanline of its repetition. If this can be done, it probably needs an unrolled loop.

 

[johannesmutlu]

5 hours ago, Kurt_Woloch said:

Yes, they can be created. The problem is bandwidth limitations, so things might get tricky. Actually, I first deemed it impossible, but the more I think about it, I figure it might just work out.

Anyway, the shapes of the sprites are stored in the VDC, so to change the shape of a sprite you have to send the new shape to the VDC, every byte of it. But they are shown on consecutive scanlines, and each scanline is doubled, so in average you have 2 scanlines to write 4 bytes of sprite shapes plus rewrite the registers so that the sprites get displayed again further down the screen once they are done. The question is if this works while they are being displayed or if the VDC has some restrictions preventing this. Also, you'd probably have to do the register re-writes all at once so there's no gap between the last scanline of a sprite and the first scanline of its repetition. If this can be done, it probably needs an unrolled loop.

 

Wow,interesting,well the only way to find out whether there are restrictions to it or not is, to try it out so that we (including homebrewers) will get the ansure to it and who knows it can open up new doors in making new games for it,,,or not.

[jimj]

I don't know anything about programming the O2, but I know there are quite a few homebrews that push the Odyssey beyond what I thought it could to.  For example H.E.R.O looks pretty good as shown in the video here:

https://videopac.nl/forum/index.php?topic=3711.new

[Kurt_Woloch]

On 3/6/2024 at 4:30 AM, jimj said:

I don't know anything about programming the O2, but I know there are quite a few homebrews that push the Odyssey beyond what I thought it could to.  For example H.E.R.O looks pretty good as shown in the video here:

https://videopac.nl/forum/index.php?topic=3711.new

Yes, indeed, it does. But I've noticed something interesting with the fuse in this game... if you set a bomb to the right of a wall, the fuse forms a black rectangle which will obstruct the right part of the wall. I don't know why this happens... could this be one of the limitations of the VDC, such as if you put two characters next to each other, they just won't overlap, but the whole 8-pixel rectangle of one character will obstruct the other one? Is that how it works? If so, this would also prevent multiple dots in different colors from being set next to each other to form a background. Instead, they would have to be at least 8 pixels apart in order to fully appear on screen.

Edited March 10 by Kurt_Woloch

[DanBoris]

17 hours ago, Kurt_Woloch said:

Yes, indeed, it does. But I've noticed something interesting with the fuse in this game... if you set a bomb to the right of a wall, the fuse forms a black rectangle which will obstruct the right part of the wall. I don't know why this happens... could this be one of the limitations of the VDC, such as if you put two characters next to each other, they just won't overlap, but the whole 8-pixel rectangle of one character will obstruct the other one? Is that how it works? If so, this would also prevent multiple dots in different colors from being set next to each other to form a background. Instead, they would have to be at least 8 pixels apart in order to fully appear on screen.

If two characters are touching, even if the pixels are blank, it will mess up the character graphic. 

 

I would like to play around with that interaction some more to see if I can figure out how the VDC hardware handles this and maybe even find a way to emulate it. Internally graphics data has to move into a shift register so it can get clocked out onto the screen one pixel at a time. Since sprites can overlap each other, there is likely one shift register for each sprite. With the characters, my assumption is that there is a single shift register that is why characters cannot overlap. 

[+pboland]

3 hours ago, DanBoris said:

If two characters are touching, even if the pixels are blank, it will mess up the character graphic. 

 

I would like to play around with that interaction some more to see if I can figure out how the VDC hardware handles this and maybe even find a way to emulate it. Internally graphics data has to move into a shift register so it can get clocked out onto the screen one pixel at a time. Since sprites can overlap each other, there is likely one shift register for each sprite. With the characters, my assumption is that there is a single shift register that is why characters cannot overlap. 

But some characters can overlap. Killer Bees is a great example of this. The beebots were made using two different standard characters overlapping. I don't know how it was done (I'm not a programmer) but, I remember reading about this "trick".

[DanBoris]

19 hours ago, pboland said:

But some characters can overlap. Killer Bees is a great example of this. The beebots were made using two different standard characters overlapping. I don't know how it was done (I'm not a programmer) but, I remember reading about this "trick".

 

I will have to look into that one. My assumption is the "corruption" that occurs when you overlap characters is predictable so certain interactions may be useful. Someone actually created a utility to figure this sort of thing out.

 

http://www.guttenbrunner.com/videopac/

Edited March 12 by DanBoris

[+pboland]

On 3/12/2024 at 10:15 AM, DanBoris said:

 

I will have to look into that one. My assumption is the "corruption" that occurs when you overlap characters is predictable so certain interactions may be useful. Someone actually created a utility to figure this sort of thing out.

 

http://www.guttenbrunner.com/videopac/

Thanks for the link. I think this is what I saw some years ago. The only issue I see with the "Sprite Builder" and the "Soundfinder" is real hardware acts a little different than emulation. It would be very helpful to have these two utilities on a physical cart. I guess I need to learn how to burn an O2 cart. 🤔