"Look confused when the library somehow breaks the entire game" is a critical step. Yo that mild parallax scroll is hot as hell. Loving these videos, obviously subbed.
On the level size problem, you could use the same technique the NES games use to save on space. Instead of using a map of individual tiles, they have this bank of 4x4 tile blocks and assemble the level out of those. You save quite a lot of memory with it.
I thought about doing that but unfortunately it wouldnt work. The memory problem i was having was vram memory. The data in vram needs to be uncompressed because thats where the graphics are actually rendered from. Thx for the suggestion still though :)
@@randomcardboardbox2396 I see. On the project i'm very slowly working on, the level data is fetched off the main ram, and just the current tilemap is on the VRAM because i can't finely define where to start etc.. so in my case is pretty beneficial as it don't burn into the main memory
This looks soooo crazy good! It feels like you mix up the buttery smooth animation of MegaMan 8 with the range of Mighty No. 9's mock up sprite design (which looked really good to anyone who is reading this) and all put into a remake of the original game. Keep on going!
Thx, megaman 8 was a heavy inspiration although the mighty no. 9 vibe was coincedence. Thx for bringing it up though, Ill prbly check some of no 9's concept art for more references.
i've been very interested in retro game development for a while now, and it's so interesting to hear about what the x16 can do thru your videos! it also helps that i just like megaman lol. i'm excited to see more :D
The music volume at the end there was pretty loud, but other than that I'm liking how this project is progressing! I'll be following any other development videos you upload. I think that once you get this stage done, things will probably get easier from there. After all, once you got the physics down, they'll apply to every new stage you make, right?
Great video. It's really interesting to see where you hit limitations with the hardware (and tools) and have to find ways to reduce memory footprint or optimize the functions.
Artist here: While its not always seen in older games... a "Bokeh" Focus effect for the background, can create a much greater sense of 3d Depth, as well as to help keep the player from getting confused with foreground & background graphical details. The added benefit, is that slightly burred + less details in the backgrounds = More potential performance levels. (and maybe even the use of More parallax layers in total... which gives even more 3d Depth effect). For a test, take a snapshot of the game screen.. with those mountains in the background. Use a simple photoshop Blur filter, only on the Mountain area.. and see how it looks for yourself. Obviously, you can vary the amount of blur you choose to use. Often the amount, is depending on just how far away the object is, away from the foreground. The closer the object... the more details that you will see. Also... in Real life (and in good artwork)... Colors are also effected by Distances (typically due to moisture in the air, effecting visuals). Colors are very vibrant, when they are within +50 feet of you. However, if you stood on top of a large hilltop, and could see several miles into the distance... you would notice that things that are farther away, have far less Saturation in the colors. You will see a lot more gray tones added to the colors... as well as some potential Mist / Fog. As a painter, we end up using more muted colors, and mixing more white into the colors, to desaturate them + add some moisture based / fog like effects. The time of day / night... effects visibility, as well as lighting + shadow effects. On a very bright and sunny day, you get a very high Contrast ratio. While a very Cloudy day, has more even lighting.. that is less dynamic (less bright brights, and shadows that are not as dark). Sunset colors can add colors to effect reflections, and add colors to the distant mist. A dude I knew, created a fantastic Side Scrolling shooter... which probably had like +8 layers of Parallax scrolling layers. The issue, is that on a particular level, you were supposed to avoid these floating mines... And that the mines that were in the background layers, looked way too similar to the foreground layers mines... making it a real nightmare to try to figure out which mines had to be avoided. By adding some blurring and a lighter color shift to the layers behind the foreground... it would have Greatly helped to tell the layers apart. Actually, a pretty good example to look at is: The Adventures of Lomax. Take a gander of some screenshots of that game, and you will notice the color differences between the foreground and background layers. The original Rayman (1), also used some mild Bokeh fuzziness on the background layer.. lighter colors, and less details (though, not quite as much as seen in Lomax).
Ive added aerial perspective to the backgrounds since this video, level art is actually the focus of the next update. But i had nvr thought of using bokeh blur for the backgrounds, but that sounds like a really good idea. I'll most likely add it to the next vid. As an artist, thx for the suggestion.
Oh, this remake will definitely be on my radar. It was introduce to the devlog through Discord and I already love it and the idea of the Commander X16. I know Mega Man 1 so much, from the original to the official PSP remake, it has already been burned into my brain. I also love like Rock's sprite so far, it's like a nice middle ground of his sprites used in from MM7 & MM8/MM&B.
This is really great! I have pre-ordered a commander X 16 for the next batch, so this is very useful. I know other people have mentioned the music loudness, but I actually have a hard time focusing on anything when music is in the background. You’re giving some really interesting information that is going to be very helpful for me. Would you consider just using the music for demos, intros, and outro? Keep up the good work!
The sprite work is really very good. Mega Man's animations are very well-done. The one thing I notice is that when he changes direction, the sprite seems to slide a bit as if there is ice physics going on, though I'm guessing this is some quirk with the sprite flipping?
yeah, megaman 1 is a bit slippery and I copied its movement. I'll update it in the future but I wanted a baseline first, because game physics aren't that hard to tweak once they're working prply
I love the updated movement! There's lots of tricks used by NES games for doing this efficiently. You've made amazing progress, it's truly impressive. One other thought, if you haven't done it already. How you organize your memory usage can also give you some speedups. If data structures are in an array, you can have jump tables. Ir you can update even game objects on even frames, and odd game objects on odd frames. You can also mix code and data for your game objects to reduce the heavy cost of certain JMP instructions and replace them with JMP absolute ones. The explanation is kinda wordy, so let me know if you want to know more about this sort of thing. There's a few approaches...(possibly) Oh, and don't forget about how zero page can speed things up. 😃
Awesome!! BTW, Sierra fan? I see Halfdome in the background 07:14 , the iconic formation that Sierra used in their logo. It's great editing, I can imagine it taking longer to do the editing than the dev work!!
So, ive cut out the sections of loud music in the video, but it'll take a few hours for the chages to show. Sry for the poor audio mixing. I'll prbly reupload the video when I release part 3.
As a megaman fangame dev, I think this is turning out really legit! I'm not sure how I feel about the added outline around all the objects, there shouldn't be issues with mega man standing out, but other than that, I'm excited to see where this goes!
Happy to see ppl like the project. The outline might not be necessary but the higher resolution makes it harder to make out smaller details, also the original game technically has outlines. Btw, what fan game are are you working on?
@@randomcardboardbox2396 Working on Mega Met, the game where every entity is a Met (the helmeted enemy you showed here). Also, with the outline, I mean the extra "glow" around the sprites, eg. the blue outline around mega man
This continues being an insanely well-made devlog! Really enjoy seeing your progress. Some feedback: - The music was a bit loud at times, maybe duck it some more while your explaining stuff? (Crisps' music sounds great though) - While I appreciate all the fancy animations you added in this video, you could definitely cut back on those and save yourself some time. I'm sure you'll figure it out. Only two videos in and you're already doing some great stuff!
Sorry i cant quite remember the first video but its great to see you making this in C. How much assembly are you using compared to c? Is a great project by the way,. Edit I see you ditched c and moved to ASM lol. Also Im loving your animations they are really good!
Not sure about exact measurements but the only things in assembly are routines to transfer data to and from ram or vram. Collisions, and updating sprites. I try to asm as little as possible to make it easier to change things
I'm surprised you went with such a high resolution. From what I've read/heard the vera vram is supposed to be super limiting the higher resolution you use, but it looks like so far you are doing just fine. I'm interested to see if you come up against a ceiling down the road adding more assets or whatever. Please consider doing some tutorials for the X16 eventually. I've been very excited about the X16 for years, but the tutorials and documentation are so poor or outdated that I decided to learn to develop for the NES in the meantime. Wishing you luck in any case, your spritework is great.
Yeah, I’m close to the ceiling right now in development but it should be good. Nvr thought of making tutorials cause I think Retro Desk did a good good with it already, but I might consider it after this project.
The damage animation looks if megaman grows suddenly and then shrinks again, I don't know if it's seems that way to someone else. Either way, great proyect. Keep it up.
@@randomcardboardbox2396 I hope so. I hope the difficulty is a little more balanced in the full game too since the original was a little unfair even for Mega Man standards
I like the documentation of how things are done. :) Something I want to point out though: The volume levels in this video are pretty unbalanced, sometimes your voice is too quiet because of the BGM and there some sudden points that have loud audio...
Thx :) Also yeah, a bunch of ppl said that, I agree, I’ll make sure I fix the audio next video. And I’ll prbly reupload this one when the next devlog comes out.
Seeing this is exactly why I was such a YM2151 evangelist earlier in the X16 history. I knew the X16 could do 16bit quality games and wanted 16bit era sounds to match. I’m curious what the ZEROPAGE conflict might have been with Zsound. I suspect your ZP declarations were done with equates / defines and not .res ?
Hey in case you want a decent reverse engineering of Mega Man to copy game logic from, I recommend the Game Maker made "Megamix" engine. It's designed to be as accurate to original as reasonably possible, and it's written in Game Maker scripting language so it's human-readable.
Imagine what it was like developing these old classic games back in the day with far fewer tools, hardly any memory, slow processors and graphics chips and often times only one or two people doing all the work!
Yeah i couldnt imagine having to program without the amount of tools we hv available now. Though i think the best thing about modern retro dev are the learning resources we hv tdy.
@@randomcardboardbox2396Yeah, the guys programing for the Atari 2600 _REALLY_ had it rough. Not only was the system itself extremely limited* but the tools were essentially: Some graph paper, a calculator part time access to a slow multi-terminal server. Most games were only 2k or 4k as well. There's a story David Crane gives (the guy who wrote "Pitfall!" for the 2600) where he says that he originally had decided to give the player only ONE chance to finish the game. But after his coworkers convinced him to give the player at least 3 chances he had a big problem: He had already used 100% of the available space allocated to him (4K). So it took him an additional 3 or 4 weeks to fine tune his code even further to make room for that additional functionality. * The 2600 only has 128 bytes - yes BYTES - of RAM and could only natively access 8k of address space without bank switching (because it used a version of the 6502 with fewer address lines to save cost, called the 6507). It also had only 20 bits - yes, BITS - of RAM to define the background and the processor had to do all the work that a video chip would normally do. But human beings are clever and they always found ways to do things, especially modern home brew coders. (Games like "Donkey Kong VCS" and "Pac-Man 8k" are truly amazing). - Donkey Kong VCS: th-cam.com/video/u_xbgz_0Ap8/w-d-xo.htmlsi=KUFUo2IyCSddwZsU - Pac-Man 8K: th-cam.com/video/LuGSGhTM1ZM/w-d-xo.htmlsi=8z8x7muviwjxlK7A&t=40
You weren't trying to interpret the source code btw, you were attempting to interpret the decompiled asm bytecode. Which is like trying to interpret code on Ultraviolence difficulty.
Yeah I know I just didn’t want to distinguish between the two in the video. That decompilation was the only thing I could find for megaman 1 at the time, so I was using for those videos. But I have found more usable reverse engineered source code since then.
Switching to ASM for the iteration over the objects was probably a bad place to start. You should look at switching to "Struct Of Arrays" for instead of "Array Of Structs". This will allow the functions that are iterating over the data to use a more contiguous memory space, as they are more than likely just using partial data in the structs to do their specific jobs. Then you can just carve out those arrays and hand them to those functions. Also, remove any pointers you can so that you aren't de-referencing in these loops. Its great to save memory, but de-referencing takes precious clock cycles. From the fact that you are storing pointers in your arrays means you are spending a lot of time de-referencing in the tight loops, and you probably could just get away with doing it once. Obviously its a balance between memory and performance, but you may be able to perform tricks by loading in enemies as structs, positioning their data into Struct Of Arrays, and doing any de-referencing at that point. Before dropping to ASM, think about your algorithm, because though you'll gain minor improvements from more optimized instructions, you might be missing out on major gains by better algorithms... which you could then optimize in asm if you still feel is necessary
Thx for the advice it was really helpful. Im a bit new to C so i was treating structs like python classes. One thing though, can you explain how i would remove function pointers again, i dont quite get it?
@@randomcardboardbox2396 Really I'm just stating that its the indirection you have that is most likely responsible for the slowdown. Your data structures are storing function pointers to mimic and OOP like methods (virtual functions) but that causes that pointer to have to be de-referenced first then called (probably via a long jump). If you instead take the methods you are calling such as _update_objects or _draw_objects and make it so any enemy can be passed to those procedures, you won't have to de-reference and jump around so much. You just need to make updating an enemy dynamic enough for your needs, so if you need to change behavior for a specific enemy type, you might need to have a lookup table that describes the transitions for example. There are plenty of ways old games do this, you should check out @NesHacker or @DisplacedGamers which have good videos describing the methods NES games used to do these things quickly. Also, lookup data oriented architecture for good explanations about reasons why its slower. One good method to help transform the methods for better speed is, just think about it as an isolated thing. Look at what its doing, figure out what data is required for it to do that, and what the best format the data could be in (least indirection / pointers, but still structured). Do you need an Array of pointers to Enemy objects? Or could you just use an Array of Enemy positions and ignore the rest of the data and skip de-referencing? An Entity Component System is nicer for humans, same way OOP is nicer to isolate a problem, but it has disadvantages that become wildly apparent on machines with such limited speed and memory.
My main clincher is the token limit. Many a... "less ambitious than it seems" project has fallen to this trap. It's a little challenging sometimes trading map tile space for graphics space... but then part of me once wanted to use it ALL as tilemap space, then code "for x color, draw n tile" in place of the entire tilemap itself (to make a map of maps?) ...and... well, I didn't get 100% of the way through THAT process either. XD
Its just to help with seeing him on the screen because it was a bit hard to pick him out of the bg before. But if it looks fine on real hardware without it i may take it out though.
Controversial take, but I'm not the biggest fan of the colored outline that everything has. I get that it's for visual clarity, but it's still kinda hard to see Mega Man to be honest.
nah its not that controversial, i didn't like it much at first but as you said i was trying to improve clarity. I didn't know this before but even though this remake technically uses the same scale as the og game, things still seem smaller. But i have come around to liking it more now so i may or may not keep it. Also PS: the real controversial take is that its spelt "coloured".
Bavkground music is way too loud. Optimization Hell music was much louder than your voice. Had to jump on the volume control multiple times to not annoy other people in the house.
You have used 2 bad ideas in one project and that is the main source of slowdowns - C and using 640x480. CA65 is know for generating bad code - huge in size, slow in execution. 640x480 will require every Sprite/tile to use 4 times the memory original would had, so 120k VRAM will burn fast for just background, the char and 2--3 types of enemies (more frames of animation, even less). So you have few options- reduce BPP, reduce 640x480 to 320x240, or stream sprite data in VRAM every Update (usually 60 times per second). P.S. Codding for X16 is fun, but design of big projects like good looking game require to start with pre-calculations of how to use the very limited (for its capability) VRAM size. So the sweet spot is - compromise, compromise, compromise :D
Yeah tbh i agree with you, the 640 resolution is a self imposed challenge to max out whay tge x16 can do. But are there better options for c compilation?
@@randomcardboardbox2396 The problem is that X16 can do it, but the 120k is a bottleneck. It has pretty much superior to every new retro and before Nintendo DS console graphic capability. Superior to even SNES, 64k where kind-a bottleneck, but it had a hidden weapon - DMA and HDMA. DMA for streaming video content, HDMA for manipulating video attributes on a fly (kind-a of what Line interrupts do, but without CPU usage). AFAIK KickC pretty much produce the best code/speed in general. Its C is not as well implemented as CA65, but it is a work in progress, so you might want to check/compare some fragments. LLVM also can produce fast code, but I'm not sure what is the current state there.
@@SquallSf I agree, the 120k of vram is kinda small, but not necessarily that bad of a bottleneck because of the speed of SD transfer. It should be possible to stream different graphics data in throughout the level. Also thx for the KickC suggestion, ill try it out next time im trying to optimize the game.
@@randomcardboardbox2396 I call it a bottleneck because you will be forced to stream some of your assets each frame or at least every few frames. That mean - CPU is busy doing it (that was the HUGE advantage of DMAs of SNES). So that reduces the time for game logic, music, I/Os ... Anyway you have 512k of RAM so with good design you will stream from baked RAM, not from SD.
Hi there! Your videos leave me very puzzled. On one hand, you have amazing writing, cool video editing, great humor, and overall engaging content. However, on the other hand - and please don't take this the wrong way - your sound quality is just God-awful. It's clear that you're highly skilled in Python, as evident from your videos. So why not use some of its many tools to isolate your voice from background noise? Additionally, it's important to duck the music under your voice to avoid overlap. This technique is known as sidechain. Your content is almost awesome, so I urge you to pay attention to the sound quality. This is just a friendly piece of advice from one of your viewers.
Thx, yeah ive gotten a lot of advice on this. Im going to improve the audio for the next video, which will hopefully be my the middle of the month. Thx again for the constructive criticism.
@@randomcardboardbox2396 Thank you for the update, it's great to know. In case any help is needed, I am happy to contribute. I work in the recording industry and deal with sound on a daily basis. I am not trying to advertise, I am simply mentioning it in case it is needed.
i was using MM1, but dont worry , im going to add options to set the movement to the MM2 style as well cause I agree MM1's movement kinda sucks. Its just there as a placeholder cause I know it at least works for the levels.
this porject is REALLY REALLY cool. Please keep working on this!!!
As an 8-bit megaman purist: You are doing such awesome work. You have my blessing to keep developing this. 😂
As an 8bit purist myself, i thank you for your bressing.
I see you studied that “Animation of Mega Man” video. Those new animations look amazing! Part 2 and I’m already SUPER proud of you! 🙌🏾
Yeah it really helped the way i approached animated everything in the demo so far.
It's really been 8 months? Please keep working on this project!
Please don’t remind me :
You've got really great production value for such a small channel!
Thx :)
"Look confused when the library somehow breaks the entire game" is a critical step.
Yo that mild parallax scroll is hot as hell. Loving these videos, obviously subbed.
yeah it is a critical step, if that it wasn't in there i might hv all my hair by the end of the project :)
On the level size problem, you could use the same technique the NES games use to save on space.
Instead of using a map of individual tiles, they have this bank of 4x4 tile blocks and assemble the level out of those.
You save quite a lot of memory with it.
I thought about doing that but unfortunately it wouldnt work. The memory problem i was having was vram memory. The data in vram needs to be uncompressed because thats where the graphics are actually rendered from. Thx for the suggestion still though :)
@@randomcardboardbox2396 I see.
On the project i'm very slowly working on, the level data is fetched off the main ram, and just the current tilemap is on the VRAM because i can't finely define where to start etc.. so in my case is pretty beneficial as it don't burn into the main memory
The story continues... love it!
I can't wait to see more. This project is amazing!
Really cool but please balance your audio out, the demo footage blew out my eardrums
Thx, and sry bout dat ill make sure the audio levels ate nrml next time :)
As a new dev to the ecosystem I'm super happy to see your work and i thank you for these devlogs
Happy to be part pf the ecosystem too, hopefully youll get to see another vid again soon.
This looks soooo crazy good!
It feels like you mix up the buttery smooth animation of MegaMan 8 with the range of Mighty No. 9's mock up sprite design (which looked really good to anyone who is reading this) and all put into a remake of the original game.
Keep on going!
Thx, megaman 8 was a heavy inspiration although the mighty no. 9 vibe was coincedence. Thx for bringing it up though, Ill prbly check some of no 9's concept art for more references.
i've been very interested in retro game development for a while now, and it's so interesting to hear about what the x16 can do thru your videos! it also helps that i just like megaman lol. i'm excited to see more :D
Oh you heard about the x16 from my video, that’s nice. Hope you get into the x16 community.
Also are you more of an x fan or oh megaman?
@@randomcardboardbox2396 i'd say classic megaman mostly because i haven't played as many x games
Awesome work! Looking forward to future videos.
Thx, looking forward to making more progress.
Awesome work man. Great explanations as well. Love hearing the Trini accent on technical vids. Keep up the great work! Looking out for updates.
The music volume at the end there was pretty loud, but other than that I'm liking how this project is progressing! I'll be following any other development videos you upload.
I think that once you get this stage done, things will probably get easier from there. After all, once you got the physics down, they'll apply to every new stage you make, right?
Yeah after the next devlog things should go much smoother. Also yeah I realise the audio is a bit too loud, should be fixed next time.
Great video. It's really interesting to see where you hit limitations with the hardware (and tools) and have to find ways to reduce memory footprint or optimize the functions.
very cool, really looking forward to the continuation of the project
Artist here: While its not always seen in older games... a "Bokeh" Focus effect for the background, can create a much greater sense of 3d Depth, as well as to help keep the player from getting confused with foreground & background graphical details. The added benefit, is that slightly burred + less details in the backgrounds = More potential performance levels. (and maybe even the use of More parallax layers in total... which gives even more 3d Depth effect).
For a test, take a snapshot of the game screen.. with those mountains in the background. Use a simple photoshop Blur filter, only on the Mountain area.. and see how it looks for yourself. Obviously, you can vary the amount of blur you choose to use. Often the amount, is depending on just how far away the object is, away from the foreground. The closer the object... the more details that you will see.
Also... in Real life (and in good artwork)... Colors are also effected by Distances (typically due to moisture in the air, effecting visuals). Colors are very vibrant, when they are within +50 feet of you. However, if you stood on top of a large hilltop, and could see several miles into the distance... you would notice that things that are farther away, have far less Saturation in the colors. You will see a lot more gray tones added to the colors... as well as some potential Mist / Fog. As a painter, we end up using more muted colors, and mixing more white into the colors, to desaturate them + add some moisture based / fog like effects.
The time of day / night... effects visibility, as well as lighting + shadow effects. On a very bright and sunny day, you get a very high Contrast ratio. While a very Cloudy day, has more even lighting.. that is less dynamic (less bright brights, and shadows that are not as dark). Sunset colors can add colors to effect reflections, and add colors to the distant mist.
A dude I knew, created a fantastic Side Scrolling shooter... which probably had like +8 layers of Parallax scrolling layers. The issue, is that on a particular level, you were supposed to avoid these floating mines... And that the mines that were in the background layers, looked way too similar to the foreground layers mines... making it a real nightmare to try to figure out which mines had to be avoided. By adding some blurring and a lighter color shift to the layers behind the foreground... it would have Greatly helped to tell the layers apart.
Actually, a pretty good example to look at is: The Adventures of Lomax. Take a gander of some screenshots of that game, and you will notice the color differences between the foreground and background layers. The original Rayman (1), also used some mild Bokeh fuzziness on the background layer.. lighter colors, and less details (though, not quite as much as seen in Lomax).
Ive added aerial perspective to the backgrounds since this video, level art is actually the focus of the next update. But i had nvr thought of using bokeh blur for the backgrounds, but that sounds like a really good idea. I'll most likely add it to the next vid. As an artist, thx for the suggestion.
Very interesting and inspiring approach to creating an object system in c!
Super sick, the sprites look insanely good. Can’t wait to see the next update!!
Oh, this remake will definitely be on my radar. It was introduce to the devlog through Discord and I already love it and the idea of the Commander X16.
I know Mega Man 1 so much, from the original to the official PSP remake, it has already been burned into my brain.
I also love like Rock's sprite so far, it's like a nice middle ground of his sprites used in from MM7 & MM8/MM&B.
Subscribing to see part 3, this already looks so cool!
Awesome video! Looking forward for a new one!
This is really great! I have pre-ordered a commander X 16 for the next batch, so this is very useful.
I know other people have mentioned the music loudness, but I actually have a hard time focusing on anything when music is in the background. You’re giving some really interesting information that is going to be very helpful for me. Would you consider just using the music for demos, intros, and outro?
Keep up the good work!
Remaking Mega Man for the Commander X16 | Optimization Hell | Devlog #2
yes… that’s what the video is called
The sprite work is really very good. Mega Man's animations are very well-done. The one thing I notice is that when he changes direction, the sprite seems to slide a bit as if there is ice physics going on, though I'm guessing this is some quirk with the sprite flipping?
yeah, megaman 1 is a bit slippery and I copied its movement. I'll update it in the future but I wanted a baseline first, because game physics aren't that hard to tweak once they're working prply
@@randomcardboardbox2396 true that. Yeah, I don't think it really needs your attention right now. It's just something I noticed.
I love the updated movement! There's lots of tricks used by NES games for doing this efficiently.
You've made amazing progress, it's truly impressive.
One other thought, if you haven't done it already. How you organize your memory usage can also give you some speedups. If data structures are in an array, you can have jump tables. Ir you can update even game objects on even frames, and odd game objects on odd frames.
You can also mix code and data for your game objects to reduce the heavy cost of certain JMP instructions and replace them with JMP absolute ones.
The explanation is kinda wordy, so let me know if you want to know more about this sort of thing. There's a few approaches...(possibly)
Oh, and don't forget about how zero page can speed things up. 😃
Nuevo sub, este proyecto tiene una pintaza increíble.
thx for the sub!
@@randomcardboardbox2396 Are you well come
Lovin' this series man!
I'm super excited for Com(ega)mander X16!
Awesome!! BTW, Sierra fan? I see Halfdome in the background 07:14 , the iconic formation that Sierra used in their logo. It's great editing, I can imagine it taking longer to do the editing than the dev work!!
Thx. Tbh I know of them but it was a coincidence. And yeah your right it did take longer to edit than the actual dev work (sadness).
So, ive cut out the sections of loud music in the video, but it'll take a few hours for the chages to show. Sry for the poor audio mixing. I'll prbly reupload the video when I release part 3.
Really cool, I hope the final game ends up being really good.
This looks gorgeous. Interested in any follow ups you might post.
As a megaman fangame dev, I think this is turning out really legit! I'm not sure how I feel about the added outline around all the objects, there shouldn't be issues with mega man standing out, but other than that, I'm excited to see where this goes!
Happy to see ppl like the project. The outline might not be necessary but the higher resolution makes it harder to make out smaller details, also the original game technically has outlines. Btw, what fan game are are you working on?
@@randomcardboardbox2396 Working on Mega Met, the game where every entity is a Met (the helmeted enemy you showed here).
Also, with the outline, I mean the extra "glow" around the sprites, eg. the blue outline around mega man
This continues being an insanely well-made devlog! Really enjoy seeing your progress.
Some feedback:
- The music was a bit loud at times, maybe duck it some more while your explaining stuff? (Crisps' music sounds great though)
- While I appreciate all the fancy animations you added in this video, you could definitely cut back on those and save yourself some time.
I'm sure you'll figure it out. Only two videos in and you're already doing some great stuff!
Great pixel art 🎨🎨
Progress!
Impressive
Thx!
Sorry i cant quite remember the first video but its great to see you making this in C. How much assembly are you using compared to c? Is a great project by the way,. Edit I see you ditched c and moved to ASM lol. Also Im loving your animations they are really good!
Not sure about exact measurements but the only things in assembly are routines to transfer data to and from ram or vram. Collisions, and updating sprites. I try to asm as little as possible to make it easier to change things
Also thx bout the animations!
Really nice vid, dude
I'm surprised you went with such a high resolution. From what I've read/heard the vera vram is supposed to be super limiting the higher resolution you use, but it looks like so far you are doing just fine. I'm interested to see if you come up against a ceiling down the road adding more assets or whatever. Please consider doing some tutorials for the X16 eventually. I've been very excited about the X16 for years, but the tutorials and documentation are so poor or outdated that I decided to learn to develop for the NES in the meantime. Wishing you luck in any case, your spritework is great.
Yeah, I’m close to the ceiling right now in development but it should be good. Nvr thought of making tutorials cause I think Retro Desk did a good good with it already, but I might consider it after this project.
The damage animation looks if megaman grows suddenly and then shrinks again, I don't know if it's seems that way to someone else. Either way, great proyect. Keep it up.
Another great video! But at around 6:19 the music is too loud and kinda hard to hear your voice.
Love watching the progress.
Yeah, I know I’m gonna fix it for next time.
Good job!! Is this gonna remake the whole game ?
Thx, i might remake all of it. The hard part is making the game engine which im going to do anyway, so it depends on how im feeling.
@@randomcardboardbox2396 I hope so. I hope the difficulty is a little more balanced in the full game too since the original was a little unfair even for Mega Man standards
I like the documentation of how things are done. :)
Something I want to point out though: The volume levels in this video are pretty unbalanced, sometimes your voice is too quiet because of the BGM and there some sudden points that have loud audio...
Thx :)
Also yeah, a bunch of ppl said that, I agree, I’ll make sure I fix the audio next video. And I’ll prbly reupload this one when the next devlog comes out.
It's a very fascinating project, but at times I couldn't understand what you were saying - the music was too loud throughout.
yeah, i know, im sry for the audio. Next time it'll be better :>
After you are finished with the game please also include the sprite sheets
Yeah i dont mind doing that. Ill probably put them out on itch.io. just curious though, what would you use them for?
@@randomcardboardbox2396 I'm not gonna use them. I'm just gonna look at it
Nice work..
Thx mate
Seeing this is exactly why I was such a YM2151 evangelist earlier in the X16 history. I knew the X16 could do 16bit quality games and wanted 16bit era sounds to match.
I’m curious what the ZEROPAGE conflict might have been with Zsound. I suspect your ZP declarations were done with equates / defines and not .res ?
This rocks
Thx :)
Hey in case you want a decent reverse engineering of Mega Man to copy game logic from, I recommend the Game Maker made "Megamix" engine. It's designed to be as accurate to original as reasonably possible, and it's written in Game Maker scripting language so it's human-readable.
i just checked out the source code on github, it should be super useful. thx for the suggestion.
@@randomcardboardbox2396Though note the player behavior is based on how Mega Man controls in MM2 and up. But enemies and bosses seem correct.
I Call This Game's Name is "Mega Man Wily Wars X16"
nice
Imagine what it was like developing these old classic games back in the day with far fewer tools, hardly any memory, slow processors and graphics chips and often times only one or two people doing all the work!
Yeah i couldnt imagine having to program without the amount of tools we hv available now. Though i think the best thing about modern retro dev are the learning resources we hv tdy.
Also i doubt that capcom will. A project like mega maker has been running for like a five years at least with several released versions.
@@randomcardboardbox2396Yeah, the guys programing for the Atari 2600 _REALLY_ had it rough. Not only was the system itself extremely limited* but the tools were essentially: Some graph paper, a calculator part time access to a slow multi-terminal server. Most games were only 2k or 4k as well. There's a story David Crane gives (the guy who wrote "Pitfall!" for the 2600) where he says that he originally had decided to give the player only ONE chance to finish the game. But after his coworkers convinced him to give the player at least 3 chances he had a big problem: He had already used 100% of the available space allocated to him (4K). So it took him an additional 3 or 4 weeks to fine tune his code even further to make room for that additional functionality.
* The 2600 only has 128 bytes - yes BYTES - of RAM and could only natively access 8k of address space without bank switching (because it used a version of the 6502 with fewer address lines to save cost, called the 6507). It also had only 20 bits - yes, BITS - of RAM to define the background and the processor had to do all the work that a video chip would normally do. But human beings are clever and they always found ways to do things, especially modern home brew coders. (Games like "Donkey Kong VCS" and "Pac-Man 8k" are truly amazing).
- Donkey Kong VCS: th-cam.com/video/u_xbgz_0Ap8/w-d-xo.htmlsi=KUFUo2IyCSddwZsU
- Pac-Man 8K: th-cam.com/video/LuGSGhTM1ZM/w-d-xo.htmlsi=8z8x7muviwjxlK7A&t=40
Quick question have you considered adding Time man or Oil man.
I wasnt thinking about it until someone else made a comment about it. But now i prbly will, once the project doesnt take too long.
@@randomcardboardbox2396 okay cool thanks. 👍😄
You weren't trying to interpret the source code btw, you were attempting to interpret the decompiled asm bytecode. Which is like trying to interpret code on Ultraviolence difficulty.
Yeah I know I just didn’t want to distinguish between the two in the video. That decompilation was the only thing I could find for megaman 1 at the time, so I was using for those videos. But I have found more usable reverse engineered source code since then.
Switching to ASM for the iteration over the objects was probably a bad place to start. You should look at switching to "Struct Of Arrays" for instead of "Array Of Structs". This will allow the functions that are iterating over the data to use a more contiguous memory space, as they are more than likely just using partial data in the structs to do their specific jobs. Then you can just carve out those arrays and hand them to those functions. Also, remove any pointers you can so that you aren't de-referencing in these loops. Its great to save memory, but de-referencing takes precious clock cycles. From the fact that you are storing pointers in your arrays means you are spending a lot of time de-referencing in the tight loops, and you probably could just get away with doing it once.
Obviously its a balance between memory and performance, but you may be able to perform tricks by loading in enemies as structs, positioning their data into Struct Of Arrays, and doing any de-referencing at that point.
Before dropping to ASM, think about your algorithm, because though you'll gain minor improvements from more optimized instructions, you might be missing out on major gains by better algorithms... which you could then optimize in asm if you still feel is necessary
Thx for the advice it was really helpful. Im a bit new to C so i was treating structs like python classes. One thing though, can you explain how i would remove function pointers again, i dont quite get it?
@@randomcardboardbox2396 Really I'm just stating that its the indirection you have that is most likely responsible for the slowdown. Your data structures are storing function pointers to mimic and OOP like methods (virtual functions) but that causes that pointer to have to be de-referenced first then called (probably via a long jump). If you instead take the methods you are calling such as _update_objects or _draw_objects and make it so any enemy can be passed to those procedures, you won't have to de-reference and jump around so much. You just need to make updating an enemy dynamic enough for your needs, so if you need to change behavior for a specific enemy type, you might need to have a lookup table that describes the transitions for example. There are plenty of ways old games do this, you should check out @NesHacker or @DisplacedGamers which have good videos describing the methods NES games used to do these things quickly. Also, lookup data oriented architecture for good explanations about reasons why its slower.
One good method to help transform the methods for better speed is, just think about it as an isolated thing. Look at what its doing, figure out what data is required for it to do that, and what the best format the data could be in (least indirection / pointers, but still structured). Do you need an Array of pointers to Enemy objects? Or could you just use an Array of Enemy positions and ignore the rest of the data and skip de-referencing? An Entity Component System is nicer for humans, same way OOP is nicer to isolate a problem, but it has disadvantages that become wildly apparent on machines with such limited speed and memory.
That's kinda cool... but honestly hella painful.
Here I thought PICO-8 was a beast to build in!! :/
Yeah but I still think the PICO 8 pretty hard to develop, especially the limited palette and resolution.
My main clincher is the token limit. Many a... "less ambitious than it seems" project has fallen to this trap. It's a little challenging sometimes trading map tile space for graphics space... but then part of me once wanted to use it ALL as tilemap space, then code "for x color, draw n tile" in place of the entire tilemap itself (to make a map of maps?) ...and... well, I didn't get 100% of the way through THAT process either. XD
do you have only two videos on your channel?
Yeah, I just started in two months ago, but I hv a new vid in the works right now.
Are you not worried about infringing copyright?
you clearly don't know anything about Capcom or Mega Man
Why does mega man have a blue aura around him?
Its just to help with seeing him on the screen because it was a bit hard to pick him out of the bg before. But if it looks fine on real hardware without it i may take it out though.
@@randomcardboardbox2396 could take it out around the enemies too other than the aura around characters this is looking fantastic.
Have you heard from Capcom about this? I would expect a nasty letter.
subscriber 666 has entered the chat.
Controversial take, but I'm not the biggest fan of the colored outline that everything has. I get that it's for visual clarity, but it's still kinda hard to see Mega Man to be honest.
nah its not that controversial, i didn't like it much at first but as you said i was trying to improve clarity. I didn't know this before but even though this remake technically uses the same scale as the og game, things still seem smaller. But i have come around to liking it more now so i may or may not keep it.
Also PS: the real controversial take is that its spelt "coloured".
Bavkground music is way too loud. Optimization Hell music was much louder than your voice. Had to jump on the volume control multiple times to not annoy other people in the house.
sry bout that, ill pay more attention to make sure the audio is normalized next time.
Next vid will be a lot more chill, so the audio should quieter regardless.
You have used 2 bad ideas in one project and that is the main source of slowdowns - C and using 640x480. CA65 is know for generating bad code - huge in size, slow in execution. 640x480 will require every Sprite/tile to use 4 times the memory original would had, so 120k VRAM will burn fast for just background, the char and 2--3 types of enemies (more frames of animation, even less).
So you have few options- reduce BPP, reduce 640x480 to 320x240, or stream sprite data in VRAM every Update (usually 60 times per second).
P.S. Codding for X16 is fun, but design of big projects like good looking game require to start with pre-calculations of how to use the very limited (for its capability) VRAM size. So the sweet spot is - compromise, compromise, compromise :D
Yeah tbh i agree with you, the 640 resolution is a self imposed challenge to max out whay tge x16 can do. But are there better options for c compilation?
Also i already planned to use a lower bpp for the background and stream in data to the vram, not every frame but when a new room is loaded.
@@randomcardboardbox2396 The problem is that X16 can do it, but the 120k is a bottleneck. It has pretty much superior to every new retro and before Nintendo DS console graphic capability. Superior to even SNES, 64k where kind-a bottleneck, but it had a hidden weapon - DMA and HDMA. DMA for streaming video content, HDMA for manipulating video attributes on a fly (kind-a of what Line interrupts do, but without CPU usage).
AFAIK KickC pretty much produce the best code/speed in general. Its C is not as well implemented as CA65, but it is a work in progress, so you might want to check/compare some fragments. LLVM also can produce fast code, but I'm not sure what is the current state there.
@@SquallSf I agree, the 120k of vram is kinda small, but not necessarily that bad of a bottleneck because of the speed of SD transfer. It should be possible to stream different graphics data in throughout the level.
Also thx for the KickC suggestion, ill try it out next time im trying to optimize the game.
@@randomcardboardbox2396 I call it a bottleneck because you will be forced to stream some of your assets each frame or at least every few frames. That mean - CPU is busy doing it (that was the HUGE advantage of DMAs of SNES). So that reduces the time for game logic, music, I/Os ...
Anyway you have 512k of RAM so with good design you will stream from baked RAM, not from SD.
please keep talking through videos!
yeah, ill prbly continue, although next video in particular isnt going to be as technical.
Hi there! Your videos leave me very puzzled. On one hand, you have amazing writing, cool video editing, great humor, and overall engaging content. However, on the other hand - and please don't take this the wrong way - your sound quality is just God-awful. It's clear that you're highly skilled in Python, as evident from your videos. So why not use some of its many tools to isolate your voice from background noise? Additionally, it's important to duck the music under your voice to avoid overlap. This technique is known as sidechain.
Your content is almost awesome, so I urge you to pay attention to the sound quality. This is just a friendly piece of advice from one of your viewers.
Thx, yeah ive gotten a lot of advice on this. Im going to improve the audio for the next video, which will hopefully be my the middle of the month. Thx again for the constructive criticism.
@@randomcardboardbox2396 Thank you for the update, it's great to know.
In case any help is needed, I am happy to contribute. I work in the recording industry and deal with sound on a daily basis. I am not trying to advertise, I am simply mentioning it in case it is needed.
Oh no...im mot sure if you were looking at the movement code for mega man from mega man 1 or not, but please don't. D= use at least MM2..
i was using MM1, but dont worry , im going to add options to set the movement to the MM2 style as well cause I agree MM1's movement kinda sucks. Its just there as a placeholder cause I know it at least works for the levels.