I'm not sure if this can significantly sped up the code, but it is possible to can have static rotation matrices instead of recomputing them for each frame. The modification would be to have the rotation angle at a fixed value and compute its sine and cosine precisely once. You have to store the rotated points at each frame, but you are doing this anyways in order to draw them. You can simply rotated this points instead of the original starting ones. So: - Define ANGLE = 0.1 in line 18, and use the opportunity to compute CS and SN there. - Remove lines 140, 2000 and 2010. - Replace PTS for RXP or RYP in lines 2030 to 2050. I don't really think that's a bottleneck, but a tiny speed boost is a speed boost after all. I imagine that the calls to HPLOT are the slowest thing in the program. Other than that, a performance test should be done to see if the 2D arrays are affecting the performance, because accessing the memory addresses may be taxing for Basic. The simple alternative to avoid the 2D arrays would be to have three separate arrays for the x, y and z coordinates.
@@TheCodingTrain there ios program for apple called renumber allows you to correct line numbers using & renumber also allows meging two basic programs into one.
This show is so cool. I like especially the retro-looking artifacts, studio, and happy atmosphere! It transposes you into the 80s when computers just entered personal homes!
@@poof65 same here. There are some frustrating days, but the vast majority of them are a lovely adventure of problem solving and lateral thinking. And the feeling you get when your program finally works and does what you've expected.... No drug could provide that feeling.
Thanks for the replies motivating me to go deeper into the coding world. I actually did get into coding... only 21 years ago. I ultimately got my degree on 3d rendering and animation but I remember I was in Java courses with the first two semesters being all about how to think in machine code and when it was time to code we were limited to the windows notepad because our teacher believed that coding programs where here only to make future generations too lazy =P
I love this series, you always find ways to create complex projects in Apple basic, while I can’t make them in JavaScript or other easier language. I think you really are a Bob Ross of programming
Please please - do not become the Bob Ross of programming. Coding Train is a "must know", and otherwise "programming with Daniel" or so. Ok, thats boring. Suggesting " "programmer's Einstein" is a bit too much I guess??
yeah but its because graphics stuff wasn't available on JavaScript until like 8 years ago with rhe introduction of the canvas element/webgl. now you can even just emulate an apple ii in html/js and do that
Being a kid from the late 70s who started programming in BASIC on my father's Sharp MZ-700 as an 8-year-old in 1985 I simply LOVE this channel!! Keep up the good work, Mr. Shiffman! Best regards from a fan in Denmark 😉
You, Ben Eater, 3Blue1Brown, Sebastian Lague and Numberphile are my favorite channels at the moment. I struggle to understand some of yhe concepts but more and more is staying in each time I re-watch these videos. Thank you for making them!
Something I've noticed as someone who's learning to code as an adult learner is how a program lives in your brain whilst writing it. When I watch this I can't get a feel for what's happening and jump to the conclusions you make because I can't image and understand the program. When I write my own code I can imagine my whole program and fully understand it. It's the strangest phenomenon. Thanks for the video. I enjoyed the throwback to writing in basic.
Yeah, people think coding is typing. But, no, code lives in your head. Typing is just how you get the code into the computer. My boss, I'm sure, doesn't understand this and thinks that I'm just slacking off when I go outside for a vape. But, no, I'm totally still working - and my best code is written outside, away from the computer. Because that's when I tend to think laterally and about the whole program's structure, and that's where you nail some amazing optimisations. Your subconscious is a way smarter coder, so give it time to fathom things out and it'll give you your best work. So when I go back in, I type some more and - bang! - it's now ten times faster than it was. The boss thinks it's slacking, failing to understand that, as code lives in your head, then I am, in fact, coding 24 / 7. Yes, even in my sleep, as I've totally woken up with an idea in my head - must have been subconsciously processing it all night long - and then tried it out to great success. Coding is thinking. Typing is just the way you explain your thoughts to the machine.
Dan: You should do all the muliply (and divide) using bit shift and addition. Use lookup table for sin and cos. Also, as you said... remove the cls and use clear line function. If possible you could clear screen every vertical blank. You'll need to read that registry. Also I would sort the drawing order so that the line drawing follows the electronic beam in the CRT. just a few suggestions from a retro demo coder.
@@dawnadmin8119 I know that's what programmers did with the Atari 2600 but at least there was a way to synchronise with the scanlines (wsync, vsync). The Apple ][ doesn't even let you do that, so it seems like a nightmare to code for.
as he is doing the same rotation on each frame there is no point in lookup tables for sin and cos, just pre-calculate a rotation matrix and reuse it every frame
oh man, when i was a kid, my dad got a Mandelbrot program for our 8086--we left it running all night and all the next day while i was at school, and my mind was pretty blown when i finally got home
You are incredible, these videos gave me a whole perspective on what my predecessors had to go through and a lot of my older coworkers' habits now make sense to me.
Honestly, what I love the most about this channel is the sheer honesty in the process. Dan makes mistakes and also makes happy accidents. It's lovely to see him to create in that fashion. It's only fair to fail to soon find the solution in the end.
As someone who already grew up with modern computers I love seeing the origins and how people did coding back then. Makes me really grateful for modern IDE's and programming languages + libraries
Now I remember why I used to write code on paper and where that habit apparently came from since I still hand write code when I’m trying to figure out how to tackle something complicated
I adore these videos. I am a second year computer science student, and I'm in the midst of learning C and C* right now. Even though the syntax and functionality between C and Basic are worlds apart, just the barebones breakdown of concepts is so useful for my understanding. I love the style, and I've always loved your energy, so keep up the great content!
That old BASIC dialect feels a little bit strange nowadays ... but for sure it felt high-tech when we were kids! Those early 8-bit computers provided a very quick and accessible way into coding to people of all ages. Apple II and other micros contained the right recipe for coding: a built in language, a code editor and a decent API for graphics, text and sound. Congrats for making these videos!
BASIC was a good entry point. But it was slow, clunky, ate half of the available memory. The Apple II also had a decent built-in "monitor" for 6502 assembly code. This was where the full power and performance could be harnessed. It's why all the best 6502 software for decades originally came from programmers who started on Apple II machines.
Yes, on my C16 that was the first thing you could do immediately and thus peeked my interest. Unfortunately not something kids have anymore, the lack of distraction back then was very nice in a sense.
I, too, wrote a mandelbrot program for my Apple II+ clone in 1987 or so. I ran it overnight and found it had only done about a third of the image, and of course wasn't all that impressive on my amber monochrome monitor. So I hauled the computer down to the family room and plugged it into the TV so I could see colour. It only got about half way through an image before my step-dad insisted I get the computer off of the floor and back to the upstairs office where it belonged. Fun times. As far as 3D animation goes, I remember being fascinated by GraFORTH. It was the second programming language I was exposed to and taught me a lot.
If you ESC edit a line that you've listed, be careful if it includes any text strings that wrap around to the next line because they'll be indented for clarity in the listing. That means you have to escape over the additional spaces added by the indentation or they'll be added into the string. You can also delete characters by escaping over them or insert characters by escaping back enough characters to type them in.
This series really made me interested in coding on retro computers. As a kid I did not have access to a proper machine and also not speaking english back then made programming really inaccessible. Even though I won't jump into apple II emulation I found that fantasy consoles (in my case pico-8) scratch a similar itch for me. Thanks for being this inspireing!
I did my Computer Science GCSE in 1983/84 and one of my 3 examination programs was a primitive 3D vector graphics application, written in BASIC on a Research Machines 480Z. I had to work out all the maths myself as there was no internet back then or even books on how to program 3D graphics. I figured out the basic principles of perspective and coordinate systems, though I ended up with this quirky method that had a fixed "vanishing point" beyond the screen in the Z axis. I still feel quite proud of that.
First optimisation would have to be remove all those multiply by zero for the Z and Y rotations that you left in. Another thing to think about is loops, the fewer the better. If you are looping three times on something to repeat that operation on three elements of the array, type them out in full instead of looping. Sure, the code is longer but it actually speeds it up a little and in BASIC every little helps.
re : 'Another thing to think about is loops, the fewer the better." No do not make the basic interpreter convert 3 times as many lines of code with twice as many numeric literals as before in each as before. Make ALL values variables. The time required by the interpreter to isolate the variable name and fetch its value is far less than the time required for fetch a string literal of a value.
@@davecarter2508 "No do not make the basic interpreter convert 3 times as many lines of code with twice as many numeric literals as before in each as before." That is wrong - the BASIC interpreters of that time had to interpretate each line of code every time it was executed: 10 A=A+1 20 A=A+1 30 A=A+1 40 A=A+1 vs 10 FOR N=1 TO 4 20 A=A+1 30 NEXT N Second code is shorter (3 lines instead of 4) but anyway the statement A=A+1 has to be interpreted 4 times and that alone take as much time as the first code. Some extra time is needed to handle the FOR NEXT statements so the first variant is faster.
@@elkeospert9188 Failed to read huh? "Make ALL values variables." Your example uses string literals, I specifically said not to, yet you used examples with them to try and say I was wrong. :(
@@davecarter2508 I dont know if Apple II Basic is faster accessing values from variables or from string literals but my point is that avoiding loops by "loop unrolling" makes sense as suggested by Galbi3000. The number of code lines increased but the number of code lines which the interpreter needs to interprete in execution of the code decreases....
@@elkeospert9188 re : "but my point is that avoiding loops by "loop unrolling" makes sense as suggested by Galbi3000." VS "That is wrong - [toward me]" Then if that was your point STICK TO IT, instead of telling me IM WRONG and then admitting YOU DONT KNOW on the subject you just told me I'm wrong on. Which you then didn't show I was wrong on at all, I mean what's the world coming to, you on the left or something? "Make ALL values variables." does not sound anything like "NO USE LOOPS" which is all you countered against. Make ALL values variables take this 10 A=A+1 20 A=A+1 ... 1000 A=A+1 and make it this 5 B=1 10 A=A+B 20 A=A+B ... 1000 A=A+B It will run faster, the interpreter must first isolate if "1" & "B" is a variable name or a letteral, from there it will either look up the binary value or have to convert the letteral to a binary which one is quicker? I KNOW, DO YOU.
In 1990, just as I graduated from High School, I set my mind to do exactly this programme. *The biggest differences were an Array to store the points for each line, then an Array of what lines connected to each other. So just a loop in the draw section to draw the right lines. * I did use an Array of the SIN and COS values (the array was multiples of time more efficient!) * In my first iteration, I also skipped the Z-Depth Perspective, but my best friend added that once he saw my code. (He was a great programmer, but I was the Mathematician in the group. He couldn't do 3D Rotation Calculations, but once he had the code he could Optimize and add stuff.) * I did this in BASIC on my CoCo2 TSR-80, almost identical performance as the Apple //e I started on. 21 Points, 23 lines (made a crude Jet Plane). * It got 2 frames every 3 seconds! (My friend typed the nearly exact code into his brand new Amiga 500 using Amiga Basic, it did 150 fps!!)
this dude would be absolutely amazing in conventional programming tutorial. I don't watch them anymore, but when I was first starting out by watching tutorials, people would just type and I copy, not actually understanding what each line meant (now it feels like common sense, but maybe I was dumb back then). This guy explains such a inefficient and low level language in so much detail and in so much more of a digestible way, than the tutorials I watched ever had,
Hahaha, you listened to the comment last episode about whiteboards being anachronistic future tech. Love the committment to the style, it's like an unusually high quality VHS!
Dont really code but still find this super fascinating. This video deserves to get way more views, interesting video plus a lot of thought and time put into the editing. 🙏🏽
The editing of your recent videos has been spectacular!! it feels so professional and dynamic and i think it's a really amazing touch! not to say your old videos aren't good lol, but this definitely adds another spark to make your videos even more engaging than they already were! props to you and your editor!!
I did something like this on the Gameboy Advance for a tank battle game. It used tables of the trig functions, and "poked" pixels directly to screen memory, then erased the old pixels on the next frame. Double buffering was too slow, or it was some other reason-- I don't recall. I found that making a solid, optimized engine before really starting the game left me with enough processing time for 60 fps gameplay.
Bring back some memories. I started programming on an Apple II when I was in elementary school. Some how managed to break out of the game Oregon Trail while playing it (hit CTRL-C accidentally i guess) and found you could edit the source code. Things just took off from there. Learned BASIC, then moved to C/C++ with some ASM. This was back in the late 80's early 90's
I played Oregon Trail on an Apple II+ when I was in grade school and found a bug in it. It did not check for negative values when you bought stuff, so you could enter a negative dollar amount and then get the positive amount added to your money.
erasing the last one is what a lot of oldschool games did, and usually for just the cost of using the x and y coordinates twice, once preparing and once clearing the frame. even if assembly was fast you're still filling in 99.9% pixels you didn't touch, even a slow line drawing routine can beat that
xy = (x2 + y2 - (x-y)2)/2 can do an 8 × 8 by three lookups in a small squaring table, of just 512 bytes, and a few additional shifts and adds. Also unroll the loops.
Daniel... You are, without a doubt, the most enjoyable UA-cam personality in history and in perpetuity. You're just absolutely delightful, unbelievably knowledgeable, a phenomenal role model both professionally and in terms of how to carry one's self. Can't wait until my kids are old enough to introduce them to your content. I deeply hope that your excitement and enthusiasm for software inspires them to love it as much as I do. Please never stop what you're doing. This channel and these videos are gifts to the world, and it's not possible for us to show enough appreciation to adequately express our appreciation.
Your computer is so cool, coding on it is really easy for me, cuz in Python, Java, C++, coding has all these really difficult keywords used to run different functions, but in Apple basic, it has simple commands like Run, Goto, Gosub etc. That’s why I love your videos and Apple Basic ❤
This series is so cool 😂 My first computer was a 286 so it was plug and play for me. Just start the computer and launch a game 😊 The only coding I had to do back then was creating a boot disk which left 640 kB of „upper memory“ and then I was good to go. I didn’t even know, that you could start coding on a computer directly without loading an operating system. So cool, now I actually want an Apple ][+ replica and try this myself. It looks really easy, when you are doing it. Actually I have to say inserting a line of code directly by typing it with a line number seems pretty convenient , as well 😊
"So cool, now I actually want an Apple ][+ replica " Where are a lot of free Apple II emulators available - so you not need by hardware if you just want try that out
@@elkeospert9188 yeah, I know. I will try something with the Raspberry 400 when my kids are older. Do you know by chance if there is a BASIC version, that connects to the GPIO pins?
Technically, the Apple boots into an OS, but it's in ROM. Basic kind of acts as a primitive UI to it. There is also Apple DOS (as you would guess, called a "disk operating system"), but it's really a disk driver. PCs had a copy of Microsoft Basic on disk. As I remember, it was called "basica". In the late '80s, Microsoft upgraded it to QuickBasic.
I love the warm retro feel to the video 🥰 This is such an awesome demonstration of how accessible programming used to be for anyone with a computer, it’s much more difficult now to know where to begin.
This series is so fun and I love all of your videos! You are the best programming teacher on youtube. Also, I love the intro and I listen to it on loop :)
Apple II was the only computer I ever got to use in school (late 80s). As the others were learning simple programming skills, me and a friend wrote a function plotter.
I don't own an old computer with basic anymore but your enthusiasm is infectious and I'm watching purely for the vibes and interesting facts about the Apple II at this point
A little short in explaining the Sine, Cosine requirements and matrix multiplication, but I really like the style of the videos, esp. including all the errors we humans make while thinking of something new and complex. It‘s showing the art of creativity, brilliant ideas and finding a way around all obstacles. You‘re very intelligent! And still have enough energy to present everything intelligibly. Thank you, it‘s fun to watch and also inspiring and didactic.
You might find these 2 videos have the additional explanations you are looking for! ua-cam.com/video/O5wjXoFrau4/v-deo.html ua-cam.com/video/p4Iz0XJY-Qk/v-deo.html
i know your intention of making these videos are probably not to motivate them, but i get motivated when i see your videos. you look so interesting to watch when you re solving a problem that it makes me motivated to go and continue on learning my stuff. thanks please keep it up.
I just started learning some coding at age 42...just for my curiosity. I ended up to this channel which I find very entertaining, incredibly well done and professionally packed. packed. Great job
What a fantastic video! You have such a magnetic personality, definitely the most excited person I've heard talk about matrix tables! I really like how you show the whole process, including the reasoning. The editing is great as well.
Love this series. You could simplify the shape entry by using data and read instructions and a for next loop to load them in. Then you could change the shape more easily.
Fun fact: When you use GOTO or GOSUB, Apple ]['s BASIC interpreter does a linear search for the line number, starting at the first line of the program. Therefore, a subroutine runs faster if you give it a lower line number. Therefore, when designing an Apple ][ program, you ideally want to reserve all the low line numbers for the most frequently-called subroutines, and put the main program at the highest line number.
@@TheCodingTrain I had no idea either, back when I was still using an Apple ][e. I guess no reference materials I had were talking about it. I found it randomly (some time within the last month!) on a site which was giving a line by line rundown on performance tweaks in some game code. Another one I found which blew my mind at the time was that if you store 1 into Z1, then this: 20 X = X + Z1 Supposedly runs faster than this: 20 X = X + 1 Which if you have a loop which is doing it every iteration, could pay off. (Literals in Applesoft BASIC apparently remain as text until the line is executed, so you pay the cost of parsing it every time it executes.)
I think I almost understand about 10% of the stuff you talk about, but, man! Do I enjoy your enthousiasm! I am glad I stumbled upon your channel and will definately come back to watch.
I was just watching a video you made 5 years ago on JS Prototypes and I had to come to a recent video to properly thank you. I've been learning how to code for the last 2 years in college and every single time I'm struggling with a concept I specifically go to your channel and hope that you've made a video about it so that I can hear it from your perspective. -- Learning this stuff can be such a dry process and you make it fun which is beyond a rare skill my friend. At this point if I make it through this program and receive a diploma, I might just replace the schools name with 'The Coding Train'. Thank you, so much.
This brings back old memories. Here are some thoughts on increasing performance (excluding reprogramming in assembly language): 1- Use pre-computed sin and cos values as you proposed yourself. 2- Deleting the entire HGR buffer on every frame takes a lot of time. This cannot be done during VSYNC as someone suggested, not even with cycle counting. The filling of the 4K bank with 0 takes almost one second and is probably the largest contributor to the lack of performance. You suggested the solution, which is to redraw the existing lines in black. Just keep 2 arrays and flip among them as you draw each page, so you always have access to the previous points, and alternate the rotate sub-routine to use either one or the other array as input according to the page you are in. 3- You might look at the shape table functionality of Applesoft. These are Applesoft driven but machine language managed drawing routines, including draw, xdraw and rot. 4- Remove those multiplications by zero from the code. 5- You might consider using integer variables for the positions on screen (by using a % on the arrays definition). Integer calculations are much faster than floating point. Or if you are up to a nice challenge, use integer basic instead. It is faster, but the challenge will be the sin/cos multiplication without FP. 6- This is more of a stretch, but if you can find a pair of sin/cos that are very close to multiples of 2, or at least very close to integer amounts, you can use shift operations for multiplication.
The routine used by HGR to clear the screen is designed for compactness and generality rather than speed, and takes about 6 times as long as an optimized clear-screen function would take. Shape-table routines likewise prioritize compactness and generality over performance. Applesoft's integer variables are slower than floating-point, and the only advantage they offer is that integer arrays are smaller than floating-point arrays.
@@flatfingertuning727 Thx for the comments. So maybe integer basic is the option for more speed. And avoiding rewriting the clear screen in assembly or machine language, we are left with drawing the lines in black to clear them quickly (hopefully).
@@nelbr Using a few pokes to create machine-code routines in memory is really the best way to go, and I don't think it's really "cheating" if the code is simple enough to be generated entirely via individual POKES (as opposed to a READ loop which processes DATA statements generated via other means). As for integer BASIC, it lacks hi-res drawing commands.
@@flatfingertuning727 You are right twice. Assembly language is obviously the best approach to write performant graphic routines and if simple enough to be achieved through pokes (maybe from within a read / data loop) then sure. I can't see a faster way of doing it.
@@nelbr In a different comment, I posted some code which POKEs in a simple but fast machine language routine containing an LDA, LDX, 32 STA (generated via loop), one INX, a BNE, and an RTS. Six different instructions, but six times as fast as the routine in ROM.
Your videos make me wanna go back in time... BASIC was fun to play with. And I understood it much better when I was 10 than I do now. Days I spent typing in lists and troubleshooting them, I still wonder how we got anything to work back then. But it worked, with just a manual, a bunch of magazines and your gray mass. Still love coding, it's amazing
When I was a kid, I wrote a program for the Apple II that created a spinning prism type polygon with a user definable number of sides, using double buffering. It could only spin though, it didn't let you rotate the object in any direction. But it was pretty fast.
I can't tell you how much I'm enjoying this series. I would genuinely enjoy seeing you do it in 6502 and seeing how they run side by side. I do love your other material, but working in such a limited hardware is such an interesting topic. More please! :D
I have not programmed on the Apple but I started on computers of the same generation. Eliminated floating point math would be good. Look up tables and fixed point math should give you a speed boost.
Great episode and great channel! I love vector graphics on 8 bits :) I dedicated almost all my channel to it. Since BASIC is interpretated, you can compress your BASIC code into as few lines as possible, starting with line number 0, 1, 2, 3, etc and maxing out the line length (max 255 chars) ...so the Interpreter will run the code faster and has fewer codelines jumps... I got amazing speedups with my 3d renderer which i also wrote in BASIC for the commodore Plus/4.
@@TheCodingTrain Also, for Atari, every GOTO, GOSUB, and loop, causes the computer to start searching for its destination at line 0. Maybe your situation is similar? We should have a line 0, which initializes a few variables, and then must GOTO the farthest set of lines like this. 0 X=1: Y=2: GOTO 32000 Line 10 is the loop that needs the fastest speed.
@@eugenetswong Why not jump directly to 32000 and do all the initalization there and then jump back to line 1 where the time critical stuff takes place. But you are right - most BASIC interpreters of that time need more time to jump to a line the more at the end the line was.
@@elkeospert9188 I can't remember my rationale for putting a few things at line 0, but it was probably the idea that we are here anyways. Other than GOTO, wht else can we add to line 0?
@@eugenetswong For code statements which are only executed once I think optimization (by putting as much code as possible in a single line) does not make much sense as the difference in runtime is very small but readability is worse.
Perfect timing, I've been meaning to try coding some simple 3d graphics on my Sinclair Spectrum for about 38 years and never really got round to looking at it, till this year! This has been very useful!
Lol, 38 years. But same here, pretty much, as a kid in the mid-80s it was my dream to program vector graphics on the C64 because I thought they were so cool (Elite, nuff said), and I even found a book in the library explaining the concepts, but as a 13-year-old, transformation matrices and all that were just way beyond me, never mind how to implement all that in assembly, so I gave up very quickly. One day...
@@csgowoes6319 Same here with the matrix transformation stuff - my brain just said no.... I am now learning z80 assembler (from the books I bought in 1983 and didn't get very far with) - so my goal is to do this in BASIC and then convert to assembler. I just have to try to resist what I did back in the day .... firing up a game instead!
I knew about the ESC editing trick. Also I recently bought an Apple IIe from eBay. Th last time I used an Apple II was in either 2002 or 2003 when I was in 5th grade.
dude john whitney and the rest of the pioneers would be so delighted to see this, i have been tinkering in this world since i found out about creative code in general, THANK YOU
This is exactly what I did when I was 12 years old in 1987 on an Apple II that my uncle gave me. There is also a low-resolution graphics mode that allowed me to write my first Tetris with each piece constructed from 4 low-res pixels.
Why am I looking that? Because it's real fun. Did this 35yrs ago with an Commodore C64 (man suddenly I'm old). Sometimes took days and how exciting it was to see something working. Even so slow as here (even slower on the C64). Thanks for th great vids!!!
I love that you included the step essential to all programmers: claiming that you give up while trying to walk away, only to be drawn back in by a new idea.
An optimization you can do in Applesoft Basic is to put subroutines you call often at the beginning of the source code (ie. low line-number). This is because when you do "GOSUB 1000" the Applesoft interpreter does a linear search through program memory for the line 1000. So your code will look something like this: 10 GOTO 1000 100 REM IMPORTANT SUBROUTINE ... 1000 REM MAIN PROGRAM
Interesting. I did something similar a Commore PET computer back when I was in high school. I had an array of points for the animated cube. Basically, it loops through the array, draws the cube, erases the screen, and draws the next frame. I got some initial help from the teacher to draw a line and clear the screen.
I love these videos! There doesn't seem to be a lot of people serious about doing anything on retro programming, it's so sad. There's something so much fun about being this close to the hardware.
I'm new to the channel, and maybe someone has said this before, but this guy is like Casper Darling who is one of the best parts of the game Control (2019)
Source code and links to all resources and references! thecodingtrain.com/challenges/175-3D-cube-applesoft-basic
I'm not sure if this can significantly sped up the code, but it is possible to can have static rotation matrices instead of recomputing them for each frame. The modification would be to have the rotation angle at a fixed value and compute its sine and cosine precisely once. You have to store the rotated points at each frame, but you are doing this anyways in order to draw them. You can simply rotated this points instead of the original starting ones. So:
- Define ANGLE = 0.1 in line 18, and use the opportunity to compute CS and SN there.
- Remove lines 140, 2000 and 2010.
- Replace PTS for RXP or RYP in lines 2030 to 2050.
I don't really think that's a bottleneck, but a tiny speed boost is a speed boost after all.
I imagine that the calls to HPLOT are the slowest thing in the program. Other than that, a performance test should be done to see if the 2D arrays are affecting the performance, because accessing the memory addresses may be taxing for Basic. The simple alternative to avoid the 2D arrays would be to have three separate arrays for the x, y and z coordinates.
@@xnick_uy Thanks for this feedback!
Mr. Train, thank you so much for this video. I love seeing how you design the features of the code and overcome obstacles.
Dan, you're a flipping legend, the enthusiasm you bring to each video is BOTTOMLESS!
@@TheCodingTrain there ios program for apple called renumber allows you to correct line numbers using & renumber also allows meging two basic programs into one.
This show is so cool. I like especially the retro-looking artifacts, studio, and happy atmosphere! It transposes you into the 80s when computers just entered personal homes!
Before that computers were only available in… professional homes? 🤨
@@theclassyox A home is professional when you work from home.
I don't even code but here I am Professor, right on time.
You should try, it's fun (I say that and this is my job 😁)
Agreed with poof65! Try these if you like! ua-cam.com/play/PLRqwX-V7Uu6Zy51Q-x9tMWIv9cueOFTFA.html
@@poof65 same here. There are some frustrating days, but the vast majority of them are a lovely adventure of problem solving and lateral thinking. And the feeling you get when your program finally works and does what you've expected.... No drug could provide that feeling.
Never too late to learn!
Thanks for the replies motivating me to go deeper into the coding world. I actually did get into coding... only 21 years ago. I ultimately got my degree on 3d rendering and animation but I remember I was in Java courses with the first two semesters being all about how to think in machine code and when it was time to code we were limited to the windows notepad because our teacher believed that coding programs where here only to make future generations too lazy =P
Daniel is the best teacher any of us could ever had had; thanks to UA-cam we do have him!!
I love this series, you always find ways to create complex projects in Apple basic, while I can’t make them in JavaScript or other easier language. I think you really are a Bob Ross of programming
Please please - do not become the Bob Ross of programming. Coding Train is a "must know", and otherwise "programming with Daniel" or so. Ok, thats boring. Suggesting " "programmer's Einstein" is a bit too much I guess??
i mean he did have experience when he was a kid
yeah but its because graphics stuff wasn't available on JavaScript until like 8 years ago with rhe introduction of the canvas element/webgl. now you can even just emulate an apple ii in html/js and do that
Being a kid from the late 70s who started programming in BASIC on my father's Sharp MZ-700 as an 8-year-old in 1985 I simply LOVE this channel!! Keep up the good work, Mr. Shiffman! Best regards from a fan in Denmark 😉
Thank you! Visited Copenhagen this past summer, hope to come back again soon!
@@TheCodingTrain Wow, nice! ☺
Perhaps you’ll also like my channel. A lot of retro and low level programming.
You, Ben Eater, 3Blue1Brown, Sebastian Lague and Numberphile are my favorite channels at the moment.
I struggle to understand some of yhe concepts but more and more is staying in each time I re-watch these videos.
Thank you for making them!
Well, I am so honored to be included on this incredible list!
same!
True, ben eater underrated
Saturday night in Ireland, cold and rainy. So nothing better than a new vid from the Dan-meister.
Sounds lovely to me, someday I hope to visit the rainy beauty of Ireland!
@@TheCodingTrain Dan, you'd be very welcome. If you ever do decide to visit, ping me and I'll hook you up with all the sights, sounds and goodies.
Something I've noticed as someone who's learning to code as an adult learner is how a program lives in your brain whilst writing it. When I watch this I can't get a feel for what's happening and jump to the conclusions you make because I can't image and understand the program. When I write my own code I can imagine my whole program and fully understand it. It's the strangest phenomenon. Thanks for the video. I enjoyed the throwback to writing in basic.
Yeah, people think coding is typing.
But, no, code lives in your head. Typing is just how you get the code into the computer.
My boss, I'm sure, doesn't understand this and thinks that I'm just slacking off when I go outside for a vape. But, no, I'm totally still working - and my best code is written outside, away from the computer. Because that's when I tend to think laterally and about the whole program's structure, and that's where you nail some amazing optimisations. Your subconscious is a way smarter coder, so give it time to fathom things out and it'll give you your best work.
So when I go back in, I type some more and - bang! - it's now ten times faster than it was.
The boss thinks it's slacking, failing to understand that, as code lives in your head, then I am, in fact, coding 24 / 7. Yes, even in my sleep, as I've totally woken up with an idea in my head - must have been subconsciously processing it all night long - and then tried it out to great success.
Coding is thinking. Typing is just the way you explain your thoughts to the machine.
Dan: You should do all the muliply (and divide) using bit shift and addition. Use lookup table for sin and cos. Also, as you said... remove the cls and use clear line function. If possible you could clear screen every vertical blank. You'll need to read that registry. Also I would sort the drawing order so that the line drawing follows the electronic beam in the CRT. just a few suggestions from a retro demo coder.
More amazing tips!
The Apple ][ has no interrupt request source. No, not even for vertical blank. Third-party expansion cards had to add them.
@@TakuikaNinja This is why game programmers “raced the beam” of the CRT by counting how many CPU cycles there were per line and blanking interval.
@@dawnadmin8119 I know that's what programmers did with the Atari 2600 but at least there was a way to synchronise with the scanlines (wsync, vsync). The Apple ][ doesn't even let you do that, so it seems like a nightmare to code for.
as he is doing the same rotation on each frame there is no point in lookup tables for sin and cos, just pre-calculate a rotation matrix and reuse it every frame
oh man, when i was a kid, my dad got a Mandelbrot program for our 8086--we left it running all night and all the next day while i was at school, and my mind was pretty blown when i finally got home
You are incredible, these videos gave me a whole perspective on what my predecessors had to go through and a lot of my older coworkers' habits now make sense to me.
Honestly, what I love the most about this channel is the sheer honesty in the process. Dan makes mistakes and also makes happy accidents. It's lovely to see him to create in that fashion. It's only fair to fail to soon find the solution in the end.
As someone who already grew up with modern computers I love seeing the origins and how people did coding back then. Makes me really grateful for modern IDE's and programming languages + libraries
I love that he shows us his mistakes as he goes. This is great.
Now I remember why I used to write code on paper and where that habit apparently came from since I still hand write code when I’m trying to figure out how to tackle something complicated
I adore these videos. I am a second year computer science student, and I'm in the midst of learning C and C* right now. Even though the syntax and functionality between C and Basic are worlds apart, just the barebones breakdown of concepts is so useful for my understanding. I love the style, and I've always loved your energy, so keep up the great content!
Thank you! this feedback means a lot to me!
Such a delight watching you harken back to a simpler time & enjoy coding on your Apple II! Retrocomputing is great fun!
LOL! You make the 80s sound like the 1800s.
That old BASIC dialect feels a little bit strange nowadays ... but for sure it felt high-tech when we were kids! Those early 8-bit computers provided a very quick and accessible way into coding to people of all ages. Apple II and other micros contained the right recipe for coding: a built in language, a code editor and a decent API for graphics, text and sound. Congrats for making these videos!
BASIC was a good entry point. But it was slow, clunky, ate half of the available memory.
The Apple II also had a decent built-in "monitor" for 6502 assembly code. This was where the full power and performance could be harnessed. It's why all the best 6502 software for decades originally came from programmers who started on Apple II machines.
Yes, on my C16 that was the first thing you could do immediately and thus peeked my interest. Unfortunately not something kids have anymore, the lack of distraction back then was very nice in a sense.
I wish my Computer studies teachers had your enthusiasm for showing how maths and coding, logic and organisation create wonderment.
I, too, wrote a mandelbrot program for my Apple II+ clone in 1987 or so. I ran it overnight and found it had only done about a third of the image, and of course wasn't all that impressive on my amber monochrome monitor. So I hauled the computer down to the family room and plugged it into the TV so I could see colour. It only got about half way through an image before my step-dad insisted I get the computer off of the floor and back to the upstairs office where it belonged. Fun times.
As far as 3D animation goes, I remember being fascinated by GraFORTH. It was the second programming language I was exposed to and taught me a lot.
Lots of folks have mentioned GraFORTH, need to check it out!
If you ESC edit a line that you've listed, be careful if it includes any text strings that wrap around to the next line because they'll be indented for clarity in the listing. That means you have to escape over the additional spaces added by the indentation or they'll be added into the string. You can also delete characters by escaping over them or insert characters by escaping back enough characters to type them in.
POKE 33,33
Takes care of some cursor inconveniences when editing lines in a LIST.
This series really made me interested in coding on retro computers.
As a kid I did not have access to a proper machine and also not speaking english back then made programming really inaccessible.
Even though I won't jump into apple II emulation I found that fantasy consoles (in my case pico-8) scratch a similar itch for me.
Thanks for being this inspireing!
I want to try the pico-8!
@@TheCodingTrain
It's a lot of fun!
Looking forward to your take on it!
pico-8? never heard of that. just checked - looks like a ton of fun! :)
The FloppyEmu is awesome. I used it to help back up some old Mac floppy disks with a Mac SE and then transfer those files to the SD.
I did my Computer Science GCSE in 1983/84 and one of my 3 examination programs was a primitive 3D vector graphics application, written in BASIC on a Research Machines 480Z. I had to work out all the maths myself as there was no internet back then or even books on how to program 3D graphics. I figured out the basic principles of perspective and coordinate systems, though I ended up with this quirky method that had a fixed "vanishing point" beyond the screen in the Z axis. I still feel quite proud of that.
i remember watching this channel in my childhood and i loved it, but i never expexted it to become a such high quality content
make graphical games, using ''if/then'' statements....10 If Ship$ = player$ then goto 50...
etc
First optimisation would have to be remove all those multiply by zero for the Z and Y rotations that you left in.
Another thing to think about is loops, the fewer the better. If you are looping three times on something to repeat that operation on three elements of the array, type them out in full instead of looping. Sure, the code is longer but it actually speeds it up a little and in BASIC every little helps.
re : 'Another thing to think about is loops, the fewer the better."
No do not make the basic interpreter convert 3 times as many lines of code with twice as many numeric literals as before in each as before.
Make ALL values variables. The time required by the interpreter to isolate the variable name and fetch its value is far less than the time required for fetch a string literal of a value.
@@davecarter2508 "No do not make the basic interpreter convert 3 times as many lines of code with twice as many numeric literals as before in each as before."
That is wrong - the BASIC interpreters of that time had to interpretate each line of code every time it was executed:
10 A=A+1
20 A=A+1
30 A=A+1
40 A=A+1
vs
10 FOR N=1 TO 4
20 A=A+1
30 NEXT N
Second code is shorter (3 lines instead of 4) but anyway the statement A=A+1 has to be interpreted 4 times and that alone take as much time as the first code. Some extra time is needed to handle the FOR NEXT statements so the first variant is faster.
@@elkeospert9188 Failed to read huh? "Make ALL values variables."
Your example uses string literals, I specifically said not to, yet you used examples with them to try and say I was wrong. :(
@@davecarter2508 I dont know if Apple II Basic is faster accessing values from variables or from string literals but my point is that avoiding loops by "loop unrolling" makes sense as suggested by Galbi3000.
The number of code lines increased but the number of code lines which the interpreter needs to interprete in execution of the code decreases....
@@elkeospert9188 re : "but my point is that avoiding loops by "loop unrolling" makes sense as suggested by Galbi3000." VS "That is wrong - [toward me]"
Then if that was your point STICK TO IT, instead of telling me IM WRONG and then admitting YOU DONT KNOW on the subject you just told me I'm wrong on.
Which you then didn't show I was wrong on at all, I mean what's the world coming to, you on the left or something?
"Make ALL values variables." does not sound anything like "NO USE LOOPS" which is all you countered against.
Make ALL values variables
take this
10 A=A+1
20 A=A+1
...
1000 A=A+1
and make it this
5 B=1
10 A=A+B
20 A=A+B
...
1000 A=A+B
It will run faster, the interpreter must first isolate if "1" & "B" is a variable name or a letteral, from there it will either look up the binary value or have to convert the letteral to a binary which one is quicker? I KNOW, DO YOU.
wow, this brings back a ton of memories. the printed banner on the wall completes the nostalgia for me.
Great video, Dan! Loving this Apple II series. The music and 80’s theme are perfect!!!
In 1990, just as I graduated from High School, I set my mind to do exactly this programme.
*The biggest differences were an Array to store the points for each line, then an Array of what lines connected to each other. So just a loop in the draw section to draw the right lines.
* I did use an Array of the SIN and COS values (the array was multiples of time more efficient!)
* In my first iteration, I also skipped the Z-Depth Perspective, but my best friend added that once he saw my code. (He was a great programmer, but I was the Mathematician in the group. He couldn't do 3D Rotation Calculations, but once he had the code he could Optimize and add stuff.)
* I did this in BASIC on my CoCo2 TSR-80, almost identical performance as the Apple //e I started on. 21 Points, 23 lines (made a crude Jet Plane).
* It got 2 frames every 3 seconds! (My friend typed the nearly exact code into his brand new Amiga 500 using Amiga Basic, it did 150 fps!!)
this dude would be absolutely amazing in conventional programming tutorial. I don't watch them anymore, but when I was first starting out by watching tutorials, people would just type and I copy, not actually understanding what each line meant (now it feels like common sense, but maybe I was dumb back then). This guy explains such a inefficient and low level language in so much detail and in so much more of a digestible way, than the tutorials I watched ever had,
Hahaha, you listened to the comment last episode about whiteboards being anachronistic future tech. Love the committment to the style, it's like an unusually high quality VHS!
Love this series, have always been into old computers and have always been into rendering
I really enjoy how genuienly excited you are to show us what you‘re doing!
Omg! Finally the video I need, I've been looking for this tutorial for 7 years!
Excellent work, great host, great content and great editing ! Love your energy, keep going
i love how you limit yourself to only using technology of the time, fun stuff!
we don't talk about 25:38 tho....
Dont really code but still find this super fascinating. This video deserves to get way more views, interesting video plus a lot of thought and time put into the editing. 🙏🏽
Thanks for this kind feedback!
The editing of your recent videos has been spectacular!! it feels so professional and dynamic and i think it's a really amazing touch! not to say your old videos aren't good lol, but this definitely adds another spark to make your videos even more engaging than they already were! props to you and your editor!!
I did something like this on the Gameboy Advance for a tank battle game. It used tables of the trig functions, and "poked" pixels directly to screen memory, then erased the old pixels on the next frame. Double buffering was too slow, or it was some other reason-- I don't recall. I found that making a solid, optimized engine before really starting the game left me with enough processing time for 60 fps gameplay.
Bring back some memories. I started programming on an Apple II when I was in elementary school. Some how managed to break out of the game Oregon Trail while playing it (hit CTRL-C accidentally i guess) and found you could edit the source code. Things just took off from there. Learned BASIC, then moved to C/C++ with some ASM. This was back in the late 80's early 90's
I played Oregon Trail on an Apple II+ when I was in grade school and found a bug in it. It did not check for negative values when you bought stuff, so you could enter a negative dollar amount and then get the positive amount added to your money.
erasing the last one is what a lot of oldschool games did, and usually for just the cost of using the x and y coordinates twice, once preparing and once clearing the frame. even if assembly was fast you're still filling in 99.9% pixels you didn't touch, even a slow line drawing routine can beat that
xy = (x2 + y2 - (x-y)2)/2 can do an 8 × 8 by three lookups in a small squaring table, of just 512 bytes, and a few additional shifts and adds. Also unroll the loops.
Great tip!
I find this series very relaxing
Daniel... You are, without a doubt, the most enjoyable UA-cam personality in history and in perpetuity. You're just absolutely delightful, unbelievably knowledgeable, a phenomenal role model both professionally and in terms of how to carry one's self.
Can't wait until my kids are old enough to introduce them to your content. I deeply hope that your excitement and enthusiasm for software inspires them to love it as much as I do.
Please never stop what you're doing. This channel and these videos are gifts to the world, and it's not possible for us to show enough appreciation to adequately express our appreciation.
Thank you this kind feedback, it means a lot!
OMG I would love to see some 6502 assembly video made by You. It would be the clearest explanation on this mystic stuff ever created :D
Wow! that line editing trick would have been so handy for me to have known in 1992
That's me, providing the cutting edge, newest tips every programmer needs!
Your computer is so cool, coding on it is really easy for me, cuz in Python, Java, C++, coding has all these really difficult keywords used to run different functions, but in Apple basic, it has simple commands like Run, Goto, Gosub etc.
That’s why I love your videos and Apple Basic ❤
This series is so cool 😂
My first computer was a 286 so it was plug and play for me. Just start the computer and launch a game 😊
The only coding I had to do back then was creating a boot disk which left 640 kB of „upper memory“ and then I was good to go.
I didn’t even know, that you could start coding on a computer directly without loading an operating system.
So cool, now I actually want an Apple ][+ replica and try this myself. It looks really easy, when you are doing it.
Actually I have to say inserting a line of code directly by typing it with a line number seems pretty convenient , as well 😊
"So cool, now I actually want an Apple ][+ replica "
Where are a lot of free Apple II emulators available - so you not need by hardware if you just want try that out
@@elkeospert9188 yeah, I know. I will try something with the Raspberry 400 when my kids are older. Do you know by chance if there is a BASIC version, that connects to the GPIO pins?
Technically, the Apple boots into an OS, but it's in ROM. Basic kind of acts as a primitive UI to it. There is also Apple DOS (as you would guess, called a "disk operating system"), but it's really a disk driver.
PCs had a copy of Microsoft Basic on disk. As I remember, it was called "basica". In the late '80s, Microsoft upgraded it to QuickBasic.
I love the warm retro feel to the video 🥰
This is such an awesome demonstration of how accessible programming used to be for anyone with a computer, it’s much more difficult now to know where to begin.
You give immense inspiration and positivity! I like to port your challenges to other languages, such as C#.
I love this series its so cool! Even if i didnt grow up with in the 80s/90s i still think its so cool to learn how you do things on old hardware
I will never write Code for an Apple II.
Still i watched the entire Video and really enjoyed it. You have great Energy!
Dude. I only recently found your channel. It is pure gold and gives my soul so much joy
This series is so fun and I love all of your videos! You are the best programming teacher on youtube.
Also, I love the intro and I listen to it on loop :)
Takes me back to the 80s, you wonderful man you! I love it.
Apple II was the only computer I ever got to use in school (late 80s).
As the others were learning simple programming skills, me and a friend wrote a function plotter.
I don't own an old computer with basic anymore but your enthusiasm is infectious and I'm watching purely for the vibes and interesting facts about the Apple II at this point
A little short in explaining the Sine, Cosine requirements and matrix multiplication, but I really like the style of the videos, esp. including all the errors we humans make while thinking of something new and complex. It‘s showing the art of creativity, brilliant ideas and finding a way around all obstacles. You‘re very intelligent! And still have enough energy to present everything intelligibly. Thank you, it‘s fun to watch and also inspiring and didactic.
You might find these 2 videos have the additional explanations you are looking for!
ua-cam.com/video/O5wjXoFrau4/v-deo.html
ua-cam.com/video/p4Iz0XJY-Qk/v-deo.html
@@TheCodingTrain Much appreciated! Thank you, I‘ll look into it.
i know your intention of making these videos are probably not to motivate them, but i get motivated when i see your videos. you look so interesting to watch when you re solving a problem that it makes me motivated to go and continue on learning my stuff. thanks please keep it up.
Man, you deserve more than this! You are the bob ross of coding. Also I want to share one of my projects with you.
I just started learning some coding at age 42...just for my curiosity. I ended up to this channel which I find very entertaining, incredibly well done and professionally packed. packed. Great job
What a fantastic video! You have such a magnetic personality, definitely the most excited person I've heard talk about matrix tables! I really like how you show the whole process, including the reasoning. The editing is great as well.
Love this series. You could simplify the shape entry by using data and read instructions and a for next loop to load them in. Then you could change the shape more easily.
Ah yes, this is an excellent point, thank you!
Fun fact: When you use GOTO or GOSUB, Apple ]['s BASIC interpreter does a linear search for the line number, starting at the first line of the program.
Therefore, a subroutine runs faster if you give it a lower line number.
Therefore, when designing an Apple ][ program, you ideally want to reserve all the low line numbers for the most frequently-called subroutines, and put the main program at the highest line number.
I did not know this!
@@TheCodingTrain I had no idea either, back when I was still using an Apple ][e. I guess no reference materials I had were talking about it. I found it randomly (some time within the last month!) on a site which was giving a line by line rundown on performance tweaks in some game code.
Another one I found which blew my mind at the time was that if you store 1 into Z1, then this:
20 X = X + Z1
Supposedly runs faster than this:
20 X = X + 1
Which if you have a loop which is doing it every iteration, could pay off. (Literals in Applesoft BASIC apparently remain as text until the line is executed, so you pay the cost of parsing it every time it executes.)
The amount of expertise, effort and soul that flow from your videos is a wonder to behold. Thank you! 🤩
I'm in love with the production values of this series
I think I almost understand about 10% of the stuff you talk about, but, man! Do I enjoy your enthousiasm! I am glad I stumbled upon your channel and will definately come back to watch.
~31:30 when you get the rotate without clearing working... I wouldn't even have been mad if you just walked away, it's pretty cool! xD
I was just watching a video you made 5 years ago on JS Prototypes and I had to come to a recent video to properly thank you. I've been learning how to code for the last 2 years in college and every single time I'm struggling with a concept I specifically go to your channel and hope that you've made a video about it so that I can hear it from your perspective. -- Learning this stuff can be such a dry process and you make it fun which is beyond a rare skill my friend. At this point if I make it through this program and receive a diploma, I might just replace the schools name with 'The Coding Train'.
Thank you, so much.
This brings back old memories. Here are some thoughts on increasing performance (excluding reprogramming in assembly language): 1- Use pre-computed sin and cos values as you proposed yourself. 2- Deleting the entire HGR buffer on every frame takes a lot of time. This cannot be done during VSYNC as someone suggested, not even with cycle counting. The filling of the 4K bank with 0 takes almost one second and is probably the largest contributor to the lack of performance. You suggested the solution, which is to redraw the existing lines in black. Just keep 2 arrays and flip among them as you draw each page, so you always have access to the previous points, and alternate the rotate sub-routine to use either one or the other array as input according to the page you are in. 3- You might look at the shape table functionality of Applesoft. These are Applesoft driven but machine language managed drawing routines, including draw, xdraw and rot. 4- Remove those multiplications by zero from the code. 5- You might consider using integer variables for the positions on screen (by using a % on the arrays definition). Integer calculations are much faster than floating point. Or if you are up to a nice challenge, use integer basic instead. It is faster, but the challenge will be the sin/cos multiplication without FP. 6- This is more of a stretch, but if you can find a pair of sin/cos that are very close to multiples of 2, or at least very close to integer amounts, you can use shift operations for multiplication.
The routine used by HGR to clear the screen is designed for compactness and generality rather than speed, and takes about 6 times as long as an optimized clear-screen function would take. Shape-table routines likewise prioritize compactness and generality over performance. Applesoft's integer variables are slower than floating-point, and the only advantage they offer is that integer arrays are smaller than floating-point arrays.
@@flatfingertuning727 Thx for the comments. So maybe integer basic is the option for more speed. And avoiding rewriting the clear screen in assembly or machine language, we are left with drawing the lines in black to clear them quickly (hopefully).
@@nelbr Using a few pokes to create machine-code routines in memory is really the best way to go, and I don't think it's really "cheating" if the code is simple enough to be generated entirely via individual POKES (as opposed to a READ loop which processes DATA statements generated via other means). As for integer BASIC, it lacks hi-res drawing commands.
@@flatfingertuning727 You are right twice. Assembly language is obviously the best approach to write performant graphic routines and if simple enough to be achieved through pokes (maybe from within a read / data loop) then sure. I can't see a faster way of doing it.
@@nelbr In a different comment, I posted some code which POKEs in a simple but fast machine language routine containing an LDA, LDX, 32 STA (generated via loop), one INX, a BNE, and an RTS. Six different instructions, but six times as fast as the routine in ROM.
Your videos make me wanna go back in time...
BASIC was fun to play with. And I understood it much better when I was 10 than I do now.
Days I spent typing in lists and troubleshooting them, I still wonder how we got anything to work back then. But it worked, with just a manual, a bunch of magazines and your gray mass.
Still love coding, it's amazing
When I was a kid, I wrote a program for the Apple II that created a spinning prism type polygon with a user definable number of sides, using double buffering. It could only spin though, it didn't let you rotate the object in any direction. But it was pretty fast.
I can't tell you how much I'm enjoying this series. I would genuinely enjoy seeing you do it in 6502 and seeing how they run side by side. I do love your other material, but working in such a limited hardware is such an interesting topic. More please! :D
love your channel! my new fav vids to watch well doing coding of my own!
Frogger was one of the few games I had on my IIc. That startup music was a touch of nostalgia.
I have not programmed on the Apple but I started on computers of the same generation. Eliminated floating point math would be good. Look up tables and fixed point math should give you a speed boost.
Great episode and great channel! I love vector graphics on 8 bits :) I dedicated almost all my channel to it. Since BASIC is interpretated, you can compress your BASIC code into as few lines as possible, starting with line number 0, 1, 2, 3, etc and maxing out the line length (max 255 chars) ...so the Interpreter will run the code faster and has fewer codelines jumps... I got amazing speedups with my 3d renderer which i also wrote in BASIC for the commodore Plus/4.
Oh cool, thank you for this note! Excited to check out your videos!
@@TheCodingTrain Also, for Atari, every GOTO, GOSUB, and loop, causes the computer to start searching for its destination at line 0. Maybe your situation is similar? We should have a line 0, which initializes a few variables, and then must GOTO the farthest set of lines like this.
0 X=1: Y=2: GOTO 32000
Line 10 is the loop that needs the fastest speed.
@@eugenetswong Why not jump directly to 32000 and do all the initalization there and then jump back to line 1 where the time critical stuff takes place.
But you are right - most BASIC interpreters of that time need more time to jump to a line the more at the end the line was.
@@elkeospert9188 I can't remember my rationale for putting a few things at line 0, but it was probably the idea that we are here anyways.
Other than GOTO, wht else can we add to line 0?
@@eugenetswong For code statements which are only executed once I think optimization (by putting as much code as possible in a single line) does not make much sense as the difference in runtime is very small but readability is worse.
Perfect timing, I've been meaning to try coding some simple 3d graphics on my Sinclair Spectrum for about 38 years and never really got round to looking at it, till this year! This has been very useful!
Lol, 38 years. But same here, pretty much, as a kid in the mid-80s it was my dream to program vector graphics on the C64 because I thought they were so cool (Elite, nuff said), and I even found a book in the library explaining the concepts, but as a 13-year-old, transformation matrices and all that were just way beyond me, never mind how to implement all that in assembly, so I gave up very quickly. One day...
@@csgowoes6319 Same here with the matrix transformation stuff - my brain just said no.... I am now learning z80 assembler (from the books I bought in 1983 and didn't get very far with) - so my goal is to do this in BASIC and then convert to assembler. I just have to try to resist what I did back in the day .... firing up a game instead!
Oh man, that Elephant Memory Systems logo @3:20 sure brought back some memories!
You can save some multiplications by merging all three rotations into a single matrix first.
This is one of my new favorite series on UA-cam. Please do more!
I knew about the ESC editing trick. Also I recently bought an Apple IIe from eBay. Th last time I used an Apple II was in either 2002 or 2003 when I was in 5th grade.
dude john whitney and the rest of the pioneers would be so delighted to see this, i have been tinkering in this world since i found out about creative code in general, THANK YOU
This is exactly what I did when I was 12 years old in 1987 on an Apple II that my uncle gave me. There is also a low-resolution graphics mode that allowed me to write my first Tetris with each piece constructed from 4 low-res pixels.
Why am I looking that? Because it's real fun. Did this 35yrs ago with an Commodore C64 (man suddenly I'm old). Sometimes took days and how exciting it was to see something working. Even so slow as here (even slower on the C64). Thanks for th great vids!!!
This guy helped me through 3 years of programming classes
Dan still one of most lovely person on UA-cam. Thank you again for your amazing work!
And thanks to the guy who taught Dan to edit lines!
I love that you included the step essential to all programmers: claiming that you give up while trying to walk away, only to be drawn back in by a new idea.
I have no idea how to do what you are doing, but your excitement is good entertainment.
An optimization you can do in Applesoft Basic is to put subroutines you call often at the beginning of the source code (ie. low line-number). This is because when you do "GOSUB 1000" the Applesoft interpreter does a linear search through program memory for the line 1000. So your code will look something like this:
10 GOTO 1000
100 REM IMPORTANT SUBROUTINE
...
1000 REM MAIN PROGRAM
Interesting. I did something similar a Commore PET computer back when I was in high school. I had an array of points for the animated cube. Basically, it loops through the array, draws the cube, erases the screen, and draws the next frame. I got some initial help from the teacher to draw a line and clear the screen.
Such a professional, you wrote the code with errors just to show us the editing function
I love these videos! There doesn't seem to be a lot of people serious about doing anything on retro programming, it's so sad. There's something so much fun about being this close to the hardware.
You'd probably like microcontroller programming stuff. Basic is interpreted so not exactly close to the metal. Look up ben eater here on youtube.
Cool ! I was waiting for some more apple 2 videos :)
I'm new to the channel, and maybe someone has said this before, but this guy is like Casper Darling who is one of the best parts of the game Control (2019)
I just love these videos. Coding is a big part of my job (aerospace; satellite dynamics engineer) and these are just super entertaining. Thanks!
Sounds like an amazing gig!
I love the opening, please keep it 🙏
your vhs skills is impossibly good
I'm loving these Apple II+ coding videos! I hope you keep making them!