Yes, yes, I know, The Count, that old blood sucker and nemesis … It is good that you keep nagging me about this
I decided to use a new teaching example for this class. I will setup a distinct project page for The Count. Soon... And continue working on the game… Soon... As quickly as possible... And finish it... Soon... Really... Eventually… Promised…
As for the "Redshirts", well, this is the story behind this:
As I have written earlier, there had been 12 students actively participating in the programming puzzles (fun) contest during the past weeks, competing for a seat on this year's programming mission (there is more story behind this going beyond the scope of this post). Thus I already had a pretty good impression of their present C programming skills. Getting such an impression was the true reason behind these trials. So, those 12 were considered to be the core team. Then 4 more latecomers showed up at yesterday's first mission briefing, who had not taken the online entry test and who had not (yet) proven to have adequate C skills. Of those 4, 3 wanted to join the mission, and I asked the core team if they were willing to take the risk of having rookies on board?
The decision was that they must wear red shirts at the next classroom meeting. Why? Well, whenever a landing party is beamed from aboard the Enterprise to some unknown planet, the well-known core team is wearing green, yellow or blue uniforms, and then there are plus one or two unknown team members in red shirts. Now guess who are the ones who always get killed once things turn ugly…
Really would like to see a yearly Programming Course Multicart for each year be published. Could fund a class party.
Agreed, I would also love to have a physical Multicart release of our classroom projects
Actually, I have given this some serious thoughts a couple of week ago. The developer of last year's "Asteroid Cowboy" was contacted by Packrat who was inquiring about the possibility of doing a physical release of the game. In that context I have briefly discussed the idea of also doing some sort of "best-of-classroom" release with Packrat, but due to lack of time I have not yet managed to pursue this any further.
The thing is, I openly admit to not being an electronics guy. I am a programmer with all my heart, and I understand how electronics work, but that is it. I am very glad that there are people out there building flash-cards and all that other stuff enabling us to run programs on the real device (a big thank you to all you guys!).
Furthermore, I simply do not have the time left to do all what is necessary for a physical release by myself. Also, in my personal case, distributing and selling cartridges, would bring along some complications. As a professor, I am an employee of the state, and I get paid for giving lectures. So I cannot simply take the results of a lecture and start selling them. Even if the money is intended to go to the Computer Science Lab, or if there is no profit and the price is just to cover the expenses. There are government regulations and local trading laws and income tax laws to be taken into account. Yeah, I know, it would be just a niche-market Vectrex thing, but those are the regulations over here.
But I could imagine the following scenario to work:
If there is someone out there who is willing to do a physical release (production, sales, distribution, ...), I would gladly grant them the right to do so (I would have to get the permission of the students as well). As far as I am concerned, they could do this in whatever fashion they like, demanding whatever price they deem fair to cover their expenses and to compensate for their own time and efforts, keeping the money for themselves. If they then freely decide to donate e.g. some physical samples as motivational material to the Computer Science Lab of our university, and send them to us as a gift, then this should be perfectly clean and avoid all complications. I would have to check, but I think this would work.
So if anybody is listening or reading this and is interested, please feel free to contact me.
A classroom party is a nice idea. I also thought of doing something like a Vectrex midnight hackathon at some point with the class, where everybody works on their project and I could do some close supervision of them all. In between we could have a break and watch "Tron" together (the original, not the sequel) in order to celebrate the Vectrex year 1982 and to show today's generation how CGI in movies should look like
A total of 17 students were present, which is 2 more than last week. So instead of people dropping out, we even grew in numbers. That came as a nice surprise, though it still remains to be seen how many will really stay with the course until the end.
Of last week’s "Redshirts", two did actually show up in a red shirt today, one of them even wearing the Starfleet Emblem
I gave an introduction to the Vectrex system in general, and to the Vectrex C programming environment we use in class. We then had a closer look at the source code of a small game demo I had prepared, and we discussed in detail how to draw vectors and vector lists.
Many of the students have also send in their first tentative ideas for a game project by now. As usual, the current status of all projects is reflected on the project gallery page, and some of the project pages already contain some concept art. More ideas should come in over the next days.
I remember when I was at University a long time ago, 1990ish, we split into teams of two and each team made a logic state machine designed in some digital logic package. My team's machine was a simple vending machine controller.
Once we'd simulated them successfully and made sure there were no glitches, the teacher packaged all the designs up and sent them to a friendly LSI chip manufacturer who made them into custom chips for us.
Then we had the pleasure of wiring the chips up with LEDs and buttons and seeing if they worked (ours did!), although there were only 6 chips for the whole class so we were careful not to blow them up. (Each chip had all the designs on it, you had to set address lines to select your machine.)
We never got to keep them, which was a shame, but now almost 30 years on, a cartridge for the current class would be a great idea!
today was the second meeting of the course. *** Of last week’s "Redshirts", two did actually show up in a red shirt today, one of them even wearing the Starfleet Emblem *** Many Cheers, Peer
LOL! Love that the students are playing the part.
I am willing to bet some Goldshirts, and Blueshirts meet their fate, and all Redshirts live on to experience life after the current season of "The Course". But really hope EVERYONE survives and thrives.
Also love that you are fully immersed. "firstname.lastname@example.org".
Last Edit: Mar 25, 2019 15:47:21 GMT -5 by VECTREXER
Thank you for the frequent updates, Peer, which gives us an idea what is going on. I had a quick look at the projects and I much like the graphic sketches of "Don't fall" (which looks like a "Floor is Lava" with perspective from above), especially the shape of the "player". "Castle vs. Castle" looks like an interesting strategic game to me. A good KI might be complex so it might start as a two-player only game.
Allen Studenten im Kurs wünsche ich viel Interessantes, viele Aha-Effekte und Erkenntnisse, guten Erfolg und eine Menge Spass!
Not much of an update, but just to keep you informed:
Last Monday, the course met for the third time. All 17 students were present, and it seems that all 17 are staying with the course. There are still 2 of them who have not yet sent in a project concept, and that is why there are still 2 projects missing on the gallery page.
We mostly talked about the Vectrex RUM functions and how interface with them and how to call them from C level. Another topic was the processor architecture of the MC6809, and we briefly revisited C structs and C unions.
At yesterday' classroom meeting I was again pleasantly surprised to find all 17 students present. This in some way is remarkable. In the past years there had always been a certain number of students dropping out during the first few weeks. This year the number actually increased
It still remains to be seen how many of them will stay until the end, but this a nice thing for a start. A total of 17 projects is way more than I had expected, and it means more management work for me to do, but it also gives me the perfect excuse why there is currently once more almost no progress on my own Vectrex game projects
The topics we discussed yesterday comprised state machines and how they are used in game programming. Also the various ways of how to implement them in C. We also did some comparisons of high-level C code and the assembly language code which is generated, assessing which C style yields the most performant machine code. In addition to that, we briefly touched the infamous "scale factor", and how to rotate vector lists by using the Vectrex RUM functions.
Almost all projects have started with early implementations or prototypes by now. The gallery page and all projects pages have been updated accordingly and now reflect the current status of the course.
Yesterday, there were actually 4 students missing in class. I guess that this was most likely related to the upcoming Easter holiday. Probably some of them have gone on vacation a bit early
There will be no lecture on Easter Monday next week, so let us see how many will attend in two weeks.
During the lecture, we ran some very early prototypes on a real Vectrex, and I gave an introduction to Vide. We then continued to discuss several game programming techniques, and dug deeper into topics like loop unrolling, function inlining, function pointers, and lookup tables and jump tables. We also talked about how to easily generate rotated vector lists. Another topic was assertion-based programming and assertion-based debugging.
All projects are on their way now, and more updates of the gallery page and the project pages will certainly follow over the next days.
In regular C there is a predefined preprocessor macro of the form "assert(<expression>)" which you get by including the system library <assert.h>. It looks like a function call, but it is in fact a macro and can be used anywhere in the code. <expression> can be any valid Boolean C expression. When used, then the C compiler will add a check to your code which evaluates the specified expression at runtime. If the result is true, program execution simply continues. If the result if false, then the program aborts and an “assertion failed" message is written to the C console window, stating the file name and the line number. This is very helpful during testing and for debugging your program. A good example is adding an assertion that checks if the index used for accessing an array element is always within the correct array bounds.
The important thing here is that such assertions are checked at runtime. Note that there is of course a tradeoff, as this means that also the runtime behavior of the program is altered. Those checks consume machine cycles. So you want them active during testing and debugging, but you do not want them included in the final binary. The good thing is that there is another C compiler macro that controls whether or not the compiler will generate assertion checks at all. So there is an easy mechanism to switch assertion checking on and off without having to alter any line of code. The recommended assertion-based programming style is to adorn your code with asserts wherever it makes sense, and to have them enabled until the final phase of a project or until you start working on program performance. Then simply disable assertion generation, but leave them in the code (in that way assertions can also be seen as some sort of in-code documentation, as they state conditions that should be valid in the line where they are specified).
Debugging Vectrex C code is difficult. There is no console window to which you can write some debug output. If you want debug output on the Vectrex screen, then you have to generate it in a loop, writing/drawing it over and over again. And there is also no <assert.h> system library.
In the past few days I therefore created a corresponding mechanism for our Vectrex C setup. I wrote a preprocessor macro for the gcc6809 compiler which mimics the functionality of the assert macro of regular C. It can be used in exactly the same way. If an assertion fails, then the important information (fail message, file name, line number) is continuously displayed in the Vectrex screen and program execution is halted.
We are now going to use this in the course, and it already proved to come in quite handy.
If any member of the past years’ courses should read this now: Sorry that I did not come up with this earlier and that you had it much harder debugging your projects