Commander X16

I've updated the dev test release on GitHuib.

First TileMap file is now map0.bin and existing Project folders must be renamed manually (including Collision Map files)
"map.bin -> map0.bin", "map0.bin -> map1.bin", "map1.bin -> map2.bin", etc

I've made a check when trying to open a Project folder where the program will exit with an error on CLI if "map.bin" is present and the GUI will refuse to open the folder.

I welcome this, will rename my maps. I don’t mind breaking changes, it is a natural part of developing software. And I have made changes in my software for just about every new release of the emulator so far, I am just happy for the improvements that are being made.

I think there is a very limited amount of users for most programs related to the X16. But we are still in the early beginning, I hope it will change when hardware is out. And you have a high number of views, so people are curious at least.

I think there is a very limited amount of users for most programs related to the X16. But we are still in the early beginning, I hope it will change when hardware is out. And you have a high number of views, so people are curious at least.

It's going to be awesome when the hardware is released. I haven't worked much on my own game lately. I'm stuck trying to get collision working with 4 top down cars and no floats
I have the Sprite Collision Interrupt working, but I just can't figure out how to move the cars/change their speeds/directions on an 8 bit system.

This is basically how I do it. I use 16-bit fixed point numbers. The 12 most significant bits represent the integer part and the 4 least represent the fraction part. This gives a precision of 1/16 which I have found is enough. Then I use a degree system where 256 = 360 degrees, in other words all directions fit perfectly in a byte. I have the following variables, all in 16 bit fixed point, for a car: car position in world (x,y), direction of car (0-255), speed of car. I also have a sin and a cos table in fixed point covering all the 256 directions.

For every frame I calculate the new position of the car with simple geometry, after that I convert the world coordinates to pixel coordinates by rounding the fixed point numbers to integers (add 8 and shift right 4 times).

For every frame I calculate the new position of the car with simple geometry, after that I convert the world coordinates to pixel coordinates by rounding the fixed point numbers to integers (add 8 and shift right 4 times).

I'm using cc65 and using its 16bit int I have physics working for 4 cars, both bots and players using joysticks, there's just no collision detection of the cars.
For physics I use values that are larger than the end result by a factor of 255 (basically fixed point 8.8). So when the calculation is done I simply divide by 255 to get the speed/direction pr car pr frame.

Regarding Collision the problem is more logical. I'm not sure how to approach it so I don't end up with an infinite loop where one car is moved into another, which is then move back and so forth forever.
I think I'm going to try and get it working on PC before starting to get the code working with fixed point.

Dacobi wrote: ↑Tue May 23, 2023 12:06 pm Regarding Collision the problem is more logical. I'm not sure how to approach it so I don't end up with an infinite loop where one car is moved into another, which is then move back and so forth forever.
I think I'm going to try and get it working on PC before starting to get the code working with fixed point.

I have avoided it by just having two racing cars. The other cars are traffic driving at the same speed distanced from each other, so they will not ever collide. But to be honest I am not totally sure that the two racing cars won't start colliding in some strange way with each other and a traffic car. When more than two cars are colliding at the same time it is hard to predict all outcomes so it sounds wise to do some tests first.

I just updated the dev release on GitHub.

Changes include:

• Sprites can be imported from Project file, PNG and RAW

• Sprite Frames are scrolled by mouse wheel

• When TileSet/Sprite Frames have scroll bars the "move up"/"move down" buttons don't scroll

• When selecting a Tile in a TileMap with BPP < 8 using "Right Click" the PaletteOffset is set to that of the selected Tile.

(Edit)
The only thing missing before the next official release is Rotation/Scale of frames by an arbitrary amount. Think I'm going to need ChatGPT for that.

Turns out getting arbitrary rotation to work is quite difficult.

I've tried some ChatGPT code with both bilinear and bicubic filtering, but there's still a lot of deformation/artifacts.

Maybe the problem is exacerbated by the small bitmap sizes of sprites, but still Gimp does a much better job.

have a look at https://github.com/salmonmoose/SpriteRotator ?

have a look at https://github.com/salmonmoose/SpriteRotator ?

I've been looking over the code, but it's a lot, and I didn't really understand the scale2x function.

What I've been trying is using SDL offscreen rendering and the SDL_RenderCopyEx where an angle can be specified.
It works a lot better than what I got from software rotation, but it still has some deformation and you will only get away with one rotation of the original bitmap.

I was hoping that by using the SDL renderer I would get the benefits of hardware filtering, but I'm not sure if that's the case.

Original: Rotated 22.5 degrees: