From my point of view it is an excellent job for these reasons:
- Smooth Scroll on Msx1 in multicolor mode
- Multicolor sprites
- Pentaro movement
- At the moment, no sprite flicker
Just a few tips:
- In testing, forget the keyboard and try to play with just the joystick (This allows for a kind of Arcade game when placed in a cabinet)
- Insert different levels maybe with password at the end of a level (this also allows on FPGA to have a kind of save state)
-At the moment I don't have audio on my computer, but I hope there is a tune, or that a nice tune has been added
Thanks again for your job
Looks really great! The only thing that "bothers" me for the moment is the way the penguin jumps. It's too linear, you need to add some gravity there. Congrats!
Nice improvent! I'll post some commets/tips as sone as I've some time.
For now I can say that sometimes the game crashes. It happens when I switch fast between moving left and right, combined with z-key pressed. This screen appears:
Player can view left and right, but will not move. After a jump the game becomes normal again (takes a second, at first player lands on the pink line).
Instead of crashing there is sometimes a litte flickering.
It's all hard to reproduce but it happened to me a few times in WEBMsx.
EDIT: Ok, I managed to reproduce and make a little videoclip.
Cool! Love the sprite status panel idea! I noticed a glitch that appeared 2 times (think it is related to diamonds drawing routine). A part of diamond is displayed over the tilemap (and flicker during the scrolling till it disappear). Sometimes killed enemies' sprites flicker in wrong position after killed and sometimes one of them last on screen. But at this early stage these glitches aren't a problem. Keep it up!
(there isn't your mail in your profile, so I can't send you the diamond glitch screenshot)
I have a suggestion too: even if in a middle of a jump or if you jump in the opposite direction you are faced the penguin should turn in the jump direction (so it should turn several times, and fast, when ascending/descending
Thanks for all the sugestions and bug reports.
About the sugestions:
-My goal is to have 6 worlds (each one themed differently, as forest, desert, water, sky, castle, etc), 4 levels per world, for a total of 24 levels, plus some mini games like small bonus stages. Yes a password system is on the plans. Restart on the first level every time you turn on the computer is not fun at all.
-Music is necessary, but I have almost zero experience with it. I will have to take a look on some source codes to get an idea.
As for the bugs: all of them are long known by me, and believe, not easy to fix. There were many, many more bugs that I already fixed, some easy, some hard to find and fix.
About the corruotes screeen bug found by Pbk71:
I can only do assumptions here, but I suppose that you copy nametable values from a RAM buffer and due to some mistake there were copied a lot of full or empty chars wich foreground (if fullfilled) or background (if empty) color is set to 0 (transparent, so border/last background color) and so we see border colors there too.
I don't know when you do copy from RAM to VRAM nametable but maybe vram addresses are changed during ISR messing that copy?
The penguin seems stuck because probably your collision detection routine doesn't include those bordercolor characters..
Thanks for all the sugestions and bug reports.
About the sugestions:
-My goal is to have 6 worlds (each one themed differently, as forest, desert, water, sky, castle, etc), 4 levels per world, for a total of 24 levels, plus some mini games like small bonus stages. Yes a password system is on the plans. Restart on the first level every time you turn on the computer is not fun at all.
-Music is necessary, but I have almost zero experience with it. I will have to take a look on some source codes to get an idea.
As for the bugs: all of them are long known by me, and believe, not easy to fix. There were many, many more bugs that I already fixed, some easy, some hard to find and fix.
It's another fascinating thing to behold taking form. Surely it will work out great!
Really looking forward to what this will become eventually.
Hi there!
I just watched a video and the scrolling look really impressive! All together it looks like you've got a solid foundation on a platformer engine.
I've noticed something though, and that's how rigidly the characters tend to jump in a lot of MSX games. It appears to me that he's jumping up and down at a set speed, probably in whole pixels. I'd like to share the approach I used for jumping characters in the past, and as far as I'm aware, this is how it's typically done for NES programmers.
I would have an X and Y position as well as an X and Y velocity for each object. You'll need 3 bytes for each position, as one byte will be screen position, one byte will be pixel position, and one byte will be sub-pixel position. Velocity will be two bytes, one for pixels and one for sub-pixels.
It looks to me like the jump now is being executed by basically adding a set number to the position every frame. We can make a smooth jump with sub-pixels and velocity.
I don't ever directly add to the value of an object's position, I modify its velocity.
Every frame, object X velocity is added to X position, and Y velocity is added to Y position. Then I do background collision and eject my object from solid titles and reset velocity to 0 if necessary.
There's also a routine for gravity, which adds to the Y velocity of every (gravity-affected) object, every frame. This will bring your character down, so falling becomes automatic. Gravity is always increasing your Y velocity, but Y velocity gets set back to 0 every time an object is ejected from a background tile on the Y axis.
All of the velocity variables need to have a maximum speed that is checked every frame. if it's too high, reset it to the maximum. You don't want this to be any higher than your smallest collision detection area.
Once this is set up, how do you make your character jump? Easy! Just give them a negative velocity that results in a jump speed you like. Gravity will naturally turn that into a smooth curve, and then reset velocity to 0 once they hit ground. You can set a jump flag if necessary so you can change the character's sprite or trigger other behaviors.
Please let me know if any of that was confusing!
Simulating gravity using fixed-point arithmetic as you suggest is a fine approach that is better than the fixed speed jump, but I find it's often hard to finetune the physics constants to get jumps that are not too "floaty". So, in my experience, just using jump tables (precalculated jump arcs, with an "escape options" in case you want to allow to control the jump height) are much easier to finetune to get the right "feeling", and is also much faster CPU-wise