Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

flstory: gfx problems #889

Closed
jotego opened this issue Dec 8, 2024 · 3 comments
Closed

flstory: gfx problems #889

jotego opened this issue Dec 8, 2024 · 3 comments

Comments

@jotego
Copy link
Owner

jotego commented Dec 8, 2024

  • scene 2, the dragon appears partially on the screen sides, it also shows some horizontal black lines

frame_00001

  • scene 5, part of the bubble covers Ptolemy -the main character- partially

frame_00001

  • in a long sim jtsim -video 800 -w 450 -inputs coin.in, lines tend to flick, especially around the main character. Trying to capture in a scene (like scene 6) does not show the problem but a long sim shows it. It might be the main problem as the black lines in the dragon

frame_00787
frame_00788

@jotego
Copy link
Owner Author

jotego commented Dec 8, 2024

Background information

The video schematics should show how everything works. What I gather from them:

  • no double line buffer, sprites to be drawn are decided during the active part of the line and drawn during blanking
  • as many as 8 sprites per line are drawn. Sprites over 8 will be drawn every other frame (flicker)
  • the video hardware is hard to understand, with a complex multiplexor driving the object RAM. In this RAM, there is the object data table written by the CPU, but the hardware also writes to it the object indexes to draw in the next line
  • the same memory also holds column scroll values for the background, but that is not used in FLSTORY

Implementation in JTFLSTORY

The sprite implementation is meant to be quite close to the original, including how the blinking is done. The differences are:

  • there is a double line buffer, instead of single line. This is done in order to relax timing and also to re-use the jtframe module
  • the original break between HB for drawing and /HB for filling the index is just done more quickly at the beginning of each line, without having to wait for the full line for the process to finish

gyurco added a commit that referenced this issue Dec 10, 2024
I have no idea about the 'blink' usage, as rendering considered 8 sprites only.
Also MAME refers the 'order' data bit 7 as some kind of priorty info, it's not used here.
@gyurco
Copy link
Collaborator

gyurco commented Dec 10, 2024

I made a PR, the sprites are OK for me. I simplified it a lot by using a single line buffer.
Flipped mode is not done, but I think it's just need some offsetting in both directions.

jotego pushed a commit that referenced this issue Dec 10, 2024
I have no idea about the 'blink' usage, as rendering considered 8 sprites only.
Also MAME refers the 'order' data bit 7 as some kind of priorty info, it's not used here.
@jotego jotego moved this to 🏗 In progress in JTCores Dec 10, 2024
@jotego
Copy link
Owner Author

jotego commented Dec 11, 2024

I think this is completed with the two PR's. Other games in the core have problems, but that would be a different issue.
Thanks @gyurco!
@jtmiki, mark as completed.

@jotego jotego closed this as completed Dec 11, 2024
@github-project-automation github-project-automation bot moved this from 🏗 In progress to To be released in JTCores Dec 11, 2024
@jotego jotego moved this from To be released to ✅ Done in JTCores Dec 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: ✅ Done
Development

No branches or pull requests

2 participants