I remember designing sprites all day, in every class in high school! lol I could never grasp lower level programming when I was young. I have been slowly learning from the ground up(Ben Eater style)...this is where I am- and it makes much more sense! You did a great presentation and I very much appreciate your decimal addressing ..its Sunday morning so I can relax! lol I hope your channel does well. Thankyou.
Thank you! When I first learned about sprites, I was super excited. I loved being able to design and control an object that could float above the background -- smoothly. And I would design sprites on paper for much of my early years, though I did design a simple sprite editor which helped a lot, and then I developed a much better one over twenty years ago. I'm a bit "old school", so you likely won't find me using a Windows program to design sprites for C64 games. I'm drawn to the "feel" of doing my work on a real C64, or even an emulator.
It is done from right to left, because binary is a "number system" exactly like decimal, where we also write the digit representing the lowest to highest values gradually from right to left. Doing it the other way around solely for the sake of graphics would make a completely unnecessary overcomplication, when programming. Since then "you" wouldn't be able to read a hexcode in say a machine-code monitor and instantly imagine the corresponding graphics in your head, with out first having to mirror the pixels... - Yes, many of us hardcore old-school coders from back then are able to do that. It involves learning by heart, a small table of the first 16 values of hexadecimal matched up to their equivalent binary values, which may sound a lot harder than it really is. Undoubtedly the inspiration for Cypher spotting the redhead just by watching the raw code of the Matrix. So: [Number-of-symbols] ^ [Digit-position]. Decimal: 10^0 = 1 10^1 = 10 10^2 = 100 10^3 = 1000 10^3 10^2 10^1 10^0 1000 100 10 1 Binary: 2^0 = 1 2^1 = 2 2^2 = 4 2^3 = 8 2^3 2^2 2^1 2^0 8 4 2 1 Hexadecimal: 16^0 = 1 16^1 = 16 16^2 = 256 16^3 = 4096 16^3 16^2 16^1 16^0 4096 256 16 1 That small 16 entry table I was babbling about: Hex Binary 0 0000 1 0001 2 0010 3 0011 4 0100 5 0101 6 0110 7 0111 8 1000 9 1001 A 1010 B 1011 C 1100 D 1101 E 1110 F 1111
I gave up trying to learn hexadecimal long ago -- I tried to learn it, but I couldn't get my brain on board, LOL. But I do get the connection between binary and hex. Your explanation goes along the lines with what I was thinking, and when it comes to designing characters, it doesn't seem to matter a whole lot when it comes to bit order (either direction isn't all that crucial). But for bitmap graphics, it certainly complicates things a little bit. But then, bitmap graphics on the C64 is a huge mess anyhow, LOL. It seems that they made bitmap graphics similar to the layout of character graphics. But having the bits run 0 to 7 and then the bytes run 0 to 39 (as opposed to 0 to 319 by step of 8) would have made the bitmap routine so much simpler, methinks (and potentially faster).
Great video, I usually drop small stuff to the tape datasette buffer 828-1019, actually you have "free" space from 820-1023, but with sprite heavy games I also just make a loader and set the start of the basic area higher, this took me like a week to figure it out, but it was very satisfying when it worked at the end! Love programing my C64 in basic, made two very crunched 5 liner games, a tetris clone, a tictactoe clone, which we regularly played with my daughter and an FPS like dungeon crawler, where you have to shoot the big one sprite monsters, it has a nice atari 2600 feel to it! Now I'm having fun making and actual dungeon crawler RPG and I also had to modify the petscii set for the map editor tool I created for the game.
Neat to hear your story! I don't think I ever moved the start of BASIC for any game I ever made. I think the reason for this is because at some point I started to use the Blitz! compiler on my games, and I don't think you can move the start of BASIC pointer when using Blitz!. I would use sprite shapes 11, 13, 14 and 15, or I would move the text screen elsewhere and have more freedom. But having to type POKE648,4 blindly so often was frustrating. After my frustrations with trying to make fast-paced games with Simon's BASIC and/or Blitz!, I decided to make my own compiler, which ultimately led to me creating Vision BASIC. Thank you for sharing your love for the C64! :)
Thank you! :) I want my videos to benefit a wide range of users no matter what their experience. And I try to include regular BASIC programming when I can. I likely won't be able to cater to a complete novice because that would require a substantially longer video. I'm glad you enjoyed it!
Making a cross compiler is outside of my skill set, and creating a cross compiler that attempts to access REU memory seems to be a major hurdle anyhow. Somebody with the proper skill set could make such a cross compiler (not associated with Vision BASIC). A lot of people unfamiliar with the C64 do not understand the limits of the machine (especially when it comes to speed). Inefficient code (from a cross compiler) would render a game that runs like molasses. Writing efficient code can be quite tricky (for certain demands). That's why most programmers use assembly language. My goal with Vision BASIC is for the programming part of it to be more "retro authentic" -- programming on the actual machine (or emulated form). Cross compilers do not permit such an authentic experience.
Vision BASIC should work with any properly emulated REU, so I cannot see a reason why it wouldn't work with the RAD. I actually own one of those myself, but haven't assembled it yet and tested it. Still, it should work. The REU is a pretty straightforward device and has simple controls. Vision BASIC has worked fine with all the other REU devices I have. The REU should have a minimum of 256K to be able to be used with Vision BASIC, though I recommend 512K or more.
@@visionbasic It all started when I got mad that people were selling these on Ebay for big bucks in violation of frntc's copyright restriction on price. I will keep a few and find homes for the others at close to cost (somewhere between 10 and 15 dollars if the batch is 100% good.)
I remember designing sprites all day, in every class in high school! lol I could never grasp lower level programming when I was young. I have been slowly learning from the ground up(Ben Eater style)...this is where I am- and it makes much more sense! You did a great presentation and I very much appreciate your decimal addressing ..its Sunday morning so I can relax! lol I hope your channel does well. Thankyou.
Thank you! When I first learned about sprites, I was super excited. I loved being able to design and control an object that could float above the background -- smoothly. And I would design sprites on paper for much of my early years, though I did design a simple sprite editor which helped a lot, and then I developed a much better one over twenty years ago. I'm a bit "old school", so you likely won't find me using a Windows program to design sprites for C64 games. I'm drawn to the "feel" of doing my work on a real C64, or even an emulator.
It is done from right to left, because binary is a "number system" exactly like decimal, where we also write the digit representing the lowest to highest values gradually from right to left. Doing it the other way around solely for the sake of graphics would make a completely unnecessary overcomplication, when programming. Since then "you" wouldn't be able to read a hexcode in say a machine-code monitor and instantly imagine the corresponding graphics in your head, with out first having to mirror the pixels...
- Yes, many of us hardcore old-school coders from back then are able to do that. It involves learning by heart, a small table of the first 16 values of hexadecimal matched up to their equivalent binary values, which may sound a lot harder than it really is. Undoubtedly the inspiration for Cypher spotting the redhead just by watching the raw code of the Matrix.
So: [Number-of-symbols] ^ [Digit-position].
Decimal:
10^0 = 1
10^1 = 10
10^2 = 100
10^3 = 1000
10^3 10^2 10^1 10^0
1000 100 10 1
Binary:
2^0 = 1
2^1 = 2
2^2 = 4
2^3 = 8
2^3 2^2 2^1 2^0
8 4 2 1
Hexadecimal:
16^0 = 1
16^1 = 16
16^2 = 256
16^3 = 4096
16^3 16^2 16^1 16^0
4096 256 16 1
That small 16 entry table I was babbling about:
Hex Binary
0 0000
1 0001
2 0010
3 0011
4 0100
5 0101
6 0110
7 0111
8 1000
9 1001
A 1010
B 1011
C 1100
D 1101
E 1110
F 1111
I gave up trying to learn hexadecimal long ago -- I tried to learn it, but I couldn't get my brain on board, LOL. But I do get the connection between binary and hex.
Your explanation goes along the lines with what I was thinking, and when it comes to designing characters, it doesn't seem to matter a whole lot when it comes to bit order (either direction isn't all that crucial). But for bitmap graphics, it certainly complicates things a little bit. But then, bitmap graphics on the C64 is a huge mess anyhow, LOL. It seems that they made bitmap graphics similar to the layout of character graphics. But having the bits run 0 to 7 and then the bytes run 0 to 39 (as opposed to 0 to 319 by step of 8) would have made the bitmap routine so much simpler, methinks (and potentially faster).
Great video, I usually drop small stuff to the tape datasette buffer 828-1019, actually you have "free" space from 820-1023, but with sprite heavy games I also just make a loader and set the start of the basic area higher, this took me like a week to figure it out, but it was very satisfying when it worked at the end! Love programing my C64 in basic, made two very crunched 5 liner games, a tetris clone, a tictactoe clone, which we regularly played with my daughter and an FPS like dungeon crawler, where you have to shoot the big one sprite monsters, it has a nice atari 2600 feel to it! Now I'm having fun making and actual dungeon crawler RPG and I also had to modify the petscii set for the map editor tool I created for the game.
Neat to hear your story! I don't think I ever moved the start of BASIC for any game I ever made. I think the reason for this is because at some point I started to use the Blitz! compiler on my games, and I don't think you can move the start of BASIC pointer when using Blitz!. I would use sprite shapes 11, 13, 14 and 15, or I would move the text screen elsewhere and have more freedom. But having to type POKE648,4 blindly so often was frustrating. After my frustrations with trying to make fast-paced games with Simon's BASIC and/or Blitz!, I decided to make my own compiler, which ultimately led to me creating Vision BASIC. Thank you for sharing your love for the C64! :)
They increase to the left so that combining multiple bytes together makes it easier to form larger numbers like 16 bit, 32, bit, etc.
Great video.
Thank you for enjoying! :)
Another great video with amazingly good explanations! Thank you.
Thank you! :) I want my videos to benefit a wide range of users no matter what their experience. And I try to include regular BASIC programming when I can. I likely won't be able to cater to a complete novice because that would require a substantially longer video. I'm glad you enjoyed it!
I wish there was some modern crosscompiling "game BASIC" for C64. Kinda like Batari BASIC or 7800BASIC, but for C64 instead of Atari.
Making a cross compiler is outside of my skill set, and creating a cross compiler that attempts to access REU memory seems to be a major hurdle anyhow. Somebody with the proper skill set could make such a cross compiler (not associated with Vision BASIC). A lot of people unfamiliar with the C64 do not understand the limits of the machine (especially when it comes to speed). Inefficient code (from a cross compiler) would render a game that runs like molasses. Writing efficient code can be quite tricky (for certain demands). That's why most programmers use assembly language. My goal with Vision BASIC is for the programming part of it to be more "retro authentic" -- programming on the actual machine (or emulated form). Cross compilers do not permit such an authentic experience.
@@visionbasic Atari 2600 is a much less powerful system than C64 and yet Batari BASIC has no issues outputting fast code.
Will Vision Basic work with frntc's RAD REU emulation?
Vision BASIC should work with any properly emulated REU, so I cannot see a reason why it wouldn't work with the RAD. I actually own one of those myself, but haven't assembled it yet and tested it. Still, it should work. The REU is a pretty straightforward device and has simple controls. Vision BASIC has worked fine with all the other REU devices I have. The REU should have a minimum of 256K to be able to be used with Vision BASIC, though I recommend 512K or more.
@@visionbasic I have 20 assembled RAD units on order from PCBWAY. If they work with vision basic, it will be a real plus.
@@networkgSo you're selling them?
@@visionbasic It all started when I got mad that people were selling these on Ebay for big bucks in violation of frntc's copyright restriction on price. I will keep a few and find homes for the others at close to cost (somewhere between 10 and 15 dollars if the batch is 100% good.)