วีดีโอ

Thanks for your comment! Much appreciated . 8580 is mostly just an improvement version of 6581 with the reliable cutoff that is linear compared to the "old" SID - as it was intended to be. But 6581 sounds more warm thanks to its imperfection. Great to have another fan of SID music. If you're into dark tunes, check out Commodore 64 Dark SID music mixtape collection I've compiled here on TH-cam ;). Let's the power of SID be with you!

Yeah! This is exactly what I do but as the whole project works on labels, I do not reference to old labels (whole build destination folder is wiped out on each build to always keep things up to date and detect false-positive address misconfiguration I've experienced in the past few times) as they might not exist anymore and the new ones might be introduced. The first pass uses fake labels (see at 14:59) as they have to exist somewhere, and all of them point to a single "whatever" place in memory. As I called it, they hang in the air, exactly like not grounded wire ;). Then, when the other module is compiled, I include these labels by compiling code again. It took me some time to re-organise the code as few of the dependencies are used in many places, so they were moved to the core. I also put a fine line between code and data, so I can easily add as many objects, NPCs, MOBs, items, magick books, spells (and their animations) and weapons as I want without making the functional code grow.

Thanks! I don't think this fix changed anything as the logic implemented in the code didn't change for the main character's sprites. In the code, these sprites are disabled the same way as before when transitioning to the new location: until a location is fully loaded. But I might miss something indeed, let me know in which video have you seen it. I probably cannot see the forest for the trees anymore :). But you have a good point! And indeed, while refactoring the engine I actually tested showing the main character on the screen as soon as possible as the new implementation allowed that. However, I reverted it as my experience of controlling the main character started to be annoying. It's because when the main character is displayed (let's say already on the top part of the screen), you want immediately to move further, however controls are disabled until the whole location is rendered. It resulted in the main character to be frozen for a while. It somehow destroys the pace of moving between locations which isn't smooth obviously due to the rendering time needed. I guess it will be easy to sense these little details once I release the demo. To be announced.

@@commocore So are you saying that you've reserved a couple of sprite numbers for the main sprite, eg. sprite number 1 (lo-res) and 0 (hi-res overlay) and then you disable those sprites (turn their enabled bits off) when you transition from "room" to "room" ? If this is the case, wouldn't it be more consistent to move the sprites to the new destination depending on how you've entered the room (from bottom to top if going down, etc.) but keep them enabled. Even if you "lock" movement, and the "rendering" of the background is still occurring, wouldn't it look more consistent ? You're right in that it might seemingly affect the flow of movement but isn't that more to do with the time taken to "render" the background ? Anyway, it's not really important but I've written a few C64 games and I know what it's like falling down the rabbit-hole trying to fix these types of little issues...

Yes, for the main sprite I reserved the first two sprites but it doesn't matter for the engine. Even that it waits for a line to be rendered, I disabled bits for the main character sprite no matter what as keeping the main character on the screen that cannot move was really annoying. The rendering have to take some time, so once location is rendered, showing the main character gives the indication that you're ready to play further. I know it's not ideal. Maybe character should leave the area and walk in, but I would need to simulate that cosmetic improvement to see how it feels before developing it. Anyways thanks for the suggestion. After releasing the first demo, I am going to gather feedback and see what to improve. I am adding this to the list of things to consider. Thanks! Can I ask what games have you worked on? I am really curious, maybe I know them? :).

​@@commocore If the rendering of the next scene/"room" is taking too long, then break it up and execute what needs to be done over successive frames BEFORE you enter the new "room". It seems you are performing this only when you enter the new "room". Based on the movement speed of the main sprite (for tolerance), define a bounding box around the exits to detect when the player is getting close to leaving the area, and then start building the next "scene" (eg. to a temporary memory block) for each frame (however much processing time you can spare) until either the operation is complete or the player has actually exited the area. At that point, the "room"/"scene" should be built and ready to go. Then simply sync with the raster, eg. at the top of the bottom border, initialise the sprites and then copy the screen RAM/colour RAM of the built new "room" to the display "window" tailoring the copy so that the raster doesn't overrun. If you achieve this, the main player won't have to be "locked" or hidden, and the next scene will seamlessly appear for the player to move immediately. This would be how I would handle this, but of course, it's up to you how you go about it.

This sounds reasonable especially when guts of this project are unknown ;). Let me break this down as it might be an interesting case study. To make that transition happen, I would need at least 11 frames (maybe half of it) just to load graphics. Player needs 16 frames to move from one tile to another so technically it's within the boundary however if you look closely, I don't animate a player to exit the location at the very edge. When it's on the last tile on the edge, character will exit immediately when direction is pressed. Moving the character further in that direction so the preloading could happen would introduce another problem. Then, player's sprites would go out into the black screen as location ends over there to the north/west/south, or straight into the side bar with party stats to the east. Stepping into a void would look weird. I would need to mask main character sprites and that's another hell of memory needed to do so. Talking about memory... I don't have too much of memory left. Size of each location is 192x176 pixels of a bitmap graphic which translates to ~4kb plus 528 bytes of colour data. I don't have enough memory to load this data on the side. Indeed, there's already an extra area I could use which preserves graphics after closing dialog boxes drawn on location (as dialogs are not displayed under the location screen as in Ultima, etc.). However, even in this case I needed to make this area slightly smaller, so technically, dialog boxes cannot actually be displayed on the very first line (which would look ugly anyways), and at the very bottom of the location. Just no free memory left. There was a lot of struggle with memory in this project, to the point I introduced swap modules that load executable code with certain features to memory while the program runs. This is not an adventure game, but quite complex cRPG that uses bitmap graphics. And this eats memory. Next, there are 2 types of locations. The first type are locations designed manually, the second type are locations generated with a seed. Time of generating a location vary here. Additionally, time to build a location even before rendering is not deterministic, as engine executes the pre-draw procedures. They are responsible to set all the elements in the location based on the conditions, and these are simply different per location. For this I use the interpreter that coordinates all the elements with a simple language and a logic chain to leave door opened, set chests already opened or objects already moved, set NPC based on conditions like day or night, or to remove it when joined the party etc. etc. and also to set the fields that are passable. This can take undetermined amount of time, and can be quite complex. So I doubt in the end that all these things could fit within the boundary but even if yes... Looking at this from wider perspective, funnily enough, currently, the main character doesn't go further at the edge of the screen, so introducing that mechanism could fix only the graphical smoothness as the main character would just walk further, but in the end, the loading + rendering time would stay the same so the timing doesn't change. The only difference is that distance would be graphically represented with the animation of the main character, but in the dimension of time, covering that distance remains the same as it is now. This is what I've found by looking at it more closely now. I don't feel there's actually anything holding the main character, as the timing it's within the pace of the movement. Probably that's why I didn't even notice it. In general I didn't find it to be a problem, but definitely it's a graphical limitation I might tackle in the future if needed.

Thanks! Interesting approach. First of all, it was a design choice for me to keep the transition this way. I didn't want to blank the screen, as copying the bitmap tiles data would take several frames. Just have a look at 5:15. Program runs in the debug mode where purple rasterlines represent copying just a single row of tiles: 192 x 16 pixels with independent colours per square). Additionaly, the status wouldn't fit at the end of the screen.

Cha cha, no tak, sam miałem dylemat, bo to jednak czysta kosmetyka . Ale wierz mi, po kilku godzinach grania naprawdę nie mogłem odgonić tej myśli i jednak stwierdziłem, że chciałbym to jednak dopieścić. Tym właśnie jest ten projekt dla mnie, nie produktem a wynikiem mojej miłości do retro i stworzenia gry, która będzie po prostu dobrze wyglądać, i równie dobrze będzie się w nią grało. I tak poszedłem tutaj na kompromis. Zdarzyć się bowiem może, że liczba wolnych sprite'ów nie jest wystarczająca. Mechanizm zwalnia wtedy potrzebną ilość "duszków" z poprzedniej lokacji. Wtedy zniknięcie sprite'a może więc nadal nastąpić . Poszedłem na kompromis, bo mógłbym zastosować multiplexing (co byłoby w sumie złożone biorąc pod uwagę ładowanie lokacji), tak, by na ekranie mogło być wyświetlone więcej niż 8 sprite'ów na raz. Więc tak czy siak mam nadzieję, że podchodzę do problemu w miarę pragmatycznie .

Thanks @ArttuTheCat! Much appreciated . Yes, 250 is near . This music track was created back in 2006+ on my Amiga 1200, and it's actually 4-tracks AHX music module. I have plenty of melodies I am planning to rewrite to 3 channels SID. It's going to be a challenge no doubt. Sending warm greetings back to Finland 🇫🇮 !

Nice !!! ❤

Thanks for your suggestion. I will take it into the consideration. Hope you will check the game once is available and let me know how does it feel now, as for diagonal shooting it would be more beneficial for larger areas where screen also moves vertically. Or, taking Contra for an example, where screen scrolls only to the left, still, there is a larger area there and characters are smaller, so the design of diagonal shooting works nicely over there. Good suggestion anyways, thanks! By diagonal jumping do you mean scrolling the screen also vertically? Because this is something I am going to do with another engine for Circus Tom game project, and for this one to leave it out by design (I think). So it would less advanced technically, but I want to focus on the gameplay to be fun.

I guess the best is just to get one for this particular model as the producer doesn't provide this information. I don't have tools with higher precision to check the thickness. I've found online that it's 0.5 to 0.6 mm thick. I don't know what the length is but I can check it for you if it helps.

Thanks @kraftwerk974! I might indeed create the assembly version as I did with another 10-liner game: Mimizuku Saga. I like this concept so I would like to explore it further with more variety, music etc. We'll see :).

Thanks @AnthonyDonker! What's best about it is that I re-use these tools and tricks across different projects.

Yay! Thanks @Goerp! Fun all the way!

Thanks a lot! More graphical touches are coming! It's time for another devlog end of this week...

Thanks a lot! Indeed, the code bit blits the object (at 3:24) from the memory location to the screen, but with the bits already shifted in the 8 pixels range (within the bits shift, object takes 3 bytes per row). It's a hi-res bitmap mode, so no characters though slightly funky rules for C64 bitmap mode apply (in the end all is 8x8 pixels grid, but to draw the graphics in the same row, it's 8 bytes further, not 1). If I understand you correctly, it would be indeed possible to move an object that is already rendered. However, I decided to always bit blit the "fresh" object on the screen for two reasons. First of all, the object appears from the bottom part of the visible area, so it's partly visible. In other words, it still needs to be blit from the source and code needs to know when to finish the rendering. The second reason is that there is also the battle screen, so after returning to the location screen I have to render this object again in the right place. This method is actually very easy, and I can freely draw any objects like that on the bitmap. For the moving clouds (again, bit shifting!), it's going to be a matter of drawing a cloud but to blit zeroes on the same bitmap after the sun is blit there.

​@@commocore thank you for your answer, that makes a lot of sense now yes, thought you might be using character mode, but it all makes so much more sense now, keep going, this project looks amazing 😍😍😍

@@c64cosmin Thanks a lot! More to come! The whole screen has to be in the bitmap mode but even if it would be in the character mode I would still need to set them dynamically as C64 has limited amount of charsets so it’s easier to draw a bitmap rather than set and copy particular charsets to the screen. Actually the first incomplete version of Meonlawel written back in BASIC used charsets but I realised quickly that it really limits how much things can be drawn, not mentioning about modifications like water or grass animations. Learning and overcoming limitations the hard way, this is what I basically learned while making this project 😅.

I didn't waste time of reading your precious comment! Should I also animate some trees?

Hail YT algorithm! Thanks a lot! Much appreciated!

Thank you for your comment!

I assume your 64NIC+ is configured and works correctly when plugged directly to the expansion port?

@@commocore it detects RRNet directly in the cartridge port but after initial data transfer it hangs and won’t receive or send any data

@@mitchmccracken3050 And how did you configure it? I used Contiki to set the configuration and test with a WEBBROWSER that was available on one of the d64 images. Maybe this guide will shed some light: commocore.com/commodorex/64nic-setup - it's for the setup of CommodoRex game I wrote. Not sure if you wanted to run my game, or play with 64NIC+ in general? Anyways, for my game, I used DHCP and IPCONFIG files from Contiki as the standard to configure 64NIC+. In any case, feel free to send me an e-mail, I will try to help you.

@@commocore it turns out the 64nic+ works fine on my c64 but it will not work on my c128 with or without the xpander :( I believe go4retro says that it simply won’t work on some c128s

@@mitchmccracken3050 thanks for the details! I've bought C128 recently, so it would be a good idea to actually check it as well. At least, happy that it works for our "tiny" C64 . Interestingly, on my C128, I cannot boot my cartridge prototype (based on Magick Desk cart) for the Meonlawel cRPG game project I am working on. I already checked that it doesn't boot from 1541Ultimate as well, so I suspect it must be a problem with the code, not with the hardware. I wonder what is the cause of 64NIC+.

Thanks! What artist or song you like the most?

@@commocore Out of the mixtape vol. 3 - when it comes to dark C64 music, Dragon's Lair Part II - song 9 by Rob Hubbard, that's the song mood that spawned Dungeon Synth music genre in the past few years, like Kobold, Gnoll and many others. Many of these are true classics.

@@LukJarzyna Oh yeah, great taste. This one reminds me another song from Rob Hubbard, Nemesis The Warlock, available on vol. 7 of this compilation. BTW. also a great unusual comic book story by Pat Mills. To be honest I have never listened to anything like Dungeon Synth as my background is mostly in industrial, so I will give it a go. Thanks :). By the way, a slightly off topic: I was honored to have a chat with Rob Hubbard during X party this year. I recommended him to check Satyagraha opera (by Philip Glass). I had really great time, he's an astonishing person still close to the Commodore 64 scene. Thanks again for your recommendations @LukJarzyna.

I actually never played it on Amiga no matter how awkward it sounds! Weird, huh? I just never got that game! Instead, I played and finished Jim Power so many many times. One of the games I play just for relax. This music, and nice gameplay. I enjoyed playing Turrican II a lot, so I am going to try the first part soon! Let me borrow that joystick from you to play it. Yay🕹!

At the time of recording it there were only plenty of people. But it was Friday, around 1pm.

Thanks!! For now, I only did a sequel called Bring Back More Bones 4k. Feel free to play both mini-games online on commocore.itch.io page. As I am in the experimental design phase of this project to see what really works, feel free to drop any suggestions! I would really appreciate it!

I didn't know about it! Thanks a lot! Do you know what pinball machines are there? I am starting to have Pinball Dreams again ;).

Serdeczne dzięki! \o/ Twoje kibicowanie bardzo wiele dla mnie znaczy więc tym bardziej nieocenione podziękowanie za wsparcie!

Thanks, Chris! Much appreciated!

This version wasn't available on CSDB while doing this video. 21 August, I mentioned about my endeavour on Twitter, as there was only Jolly Roger's crack available back then. This is also stated on the Lost Sectors channel, as folks tried to play that only version 1.0 available for C64. If you check the CSDB page creation of Lord Crass crack, it was added by Paladin on 2023-08-22 13:30:03+00 and it's a version 1.2. So indeed, now there's another version. I don't think this is a coincidence. Glad this version is there for anyone to play. I am happy to have the original anyway. Are you going to play it?

Yeah, good observation. In the following part I was going to mention indeed about that but in the context of making backups as I needed to break the protection in order to preserve/backup it. I guess, back then not everyone would think of making a backup as we tend to think nowadays?

I never played any SSI games, neither on C64 or Amiga. Demon's Winter was really fun to play even though it was tough to finish it as I didn't start the proper way. With some learnings, I think I will enjoy Shard of Spring, especially that I already enjoyed trying it out for the first 30 minutes. I wonder what have you played on Amiga, any recommendations, Arttu?

@@commocore I could recommend these SSI games on the Commodore 64 and Amiga: - ROADWAR 2000 - ROADWAR EUROPE - PHANTASIE - PHANTASIE III - BUCK ROGERS - EYE OF THE BEHOLDER - EYE OF THE BEHOLDER II 😺👍

@@ArttuTheCat Oh yeah, I tried Roadwar 2000 but on C64, it was super tough :). Thanks, I am definitely going to add it on the top of my wishlist.

Have you finished Tai Chi Tortoise? :). Haha, funny memories. I remember yet another cover that was so promising, but the game was a completely different story - Scary Bear :D. I might play it again at some point! Pozdrawiam!

Haha, I didn't notice this threat to hackers before :D. Yeah, in this game you cannot duck and you cannot shoot while being in the air. I might try to play it again with shooting blindly before making any jumps, and see if this can help to move further in the game.

Agree. Once I realise it's too hectic and unplayable, that's the sign I play it not the way intended to be played. So, there might be other way like trying to avoid enemies, or shooting blindly ahead, or... the game is just really unfair and lands in the unplayable category forever until I found out someone else beat it :D.

Actually, one of the sprite characters looks similar though closer to E.T. Guest appearance?

Welcome to the Pleasure Dome! 😄 What have you played in the past the most?

@@commocore not much, but I have been able to play some of these games on consoles since the cabinets are no longer available (which really sucks when you think about it. Keeping these cabinets could ensure more can come, but especially the Mortal Kombat games in there, since they have 1 to UMK3) I wish one day, I could actually get the arcade cab for one of the games in there, and not having to do it from Arcade1UP instead

Oh. I've never ever had 1571-II. It's a great piece of hardware - only that I know! Have a great and relaxed September vacations, Arrtu! 👾