How does page flipping work?

Página 2/3
1 | | 3

Por Driehoogvoor

Resident (52)

Imagen del Driehoogvoor

16-08-2014, 10:41

Thanks, Hit! Your post came at the perfect time—I was trying to code exactly this right now. Smile Your code is amazingly fast, but I understand it. I didn't even know you could use the stack pointer and then just pop a couple of times like that. That's an awesome trick. Or, well, feature, I guess.

And yes, I had to slow down some VDP routines already. The player sprite animation was way too fast, and the scrolling should only happen every 8 or 10 frames while running the game. Which is good, because then I basically have 8 or 10 frames to get stuff ready for rendering. Smile

Por Driehoogvoor

Resident (52)

Imagen del Driehoogvoor

16-08-2014, 10:49

I'll dive into your collision detection post later today. I want to focus on finishing the scrolling first, but I think I understand what you mean. The game I'm trying to build only has the player moving, and only interacting with the world. There are no enemies, bullets, etc. In JavaScript I did something that resembles bounding box checking by using modulus. Your code will really help in figuring out how to translate that to assembly, thanks!

Por Grauw

Ascended (10565)

Imagen del Grauw

16-08-2014, 11:47

Index registers are heaven. I use them all the time in Synthesix. Don’t be scared by their relative slowness, because when operating on structured data they can often do in 1 instruction what you need multiple instructions for with regular registers, mostly compensating for the speed difference, and the code is much more readable and maintainable than it is without.

It’s important to optimise effectively, and only where needed, because optimisation always comes at a cost. Much later in the project, I will optimise some often-used module cores to use generated self-modifying code which is very high performance, but as this can get pretty hairy I want to avoid it as much as possible. Also there are much more effective and less invasive optimisations I can do first.

Note that getting working code is way more important than getting super optimised code and then dropping the project halfway because progress is too slow. Optimisation is tempting, and fun, but also a huge time-waster and code obfuscator. Looking at your JavaScript game and the speed at which it moves, I see a lot of opportunity for optimisations which are going to be totally irrelevant to the overall game performance Smile.

I’m just stressing this point cause it’s been a pit I’ve fallen into myself several times Smile.

Por Driehoogvoor

Resident (52)

Imagen del Driehoogvoor

16-08-2014, 11:55

Haha, I know what you mean. Right now, I'm trying to make some proof of concepts—from simple stuff like drawing a sprite and reading keyboard input via the PPI to page flipping and screen splits. The focus is making them work, but also to try out some different things in assembly to learn what's fast and what's not. So I'm not really seeing it as over-optimizing, but as learning the language.

I totally agree with you that optimization is for later in a project and that micro-optimizing right at the start is a total waste of time and energy. The JavaScript code is written to be modular and extensible, not speed optimization. Modern computers and browsers process JavaScript so fast that it doesn't really matter. The game doesn't drop any frames and runs really stable on my almost four year old MacBook, so I'm happy with it. Smile

Those index registers are really awesome. I'm playing around with them right now for my smooth scroll code. The MSX really surprises me with its speed sometimes. This has been such a fun week. Big smile

Por jltursan

Prophet (2619)

Imagen del jltursan

16-08-2014, 13:50

Quote:

You can find the work in progress here (it needs decent level generation and some other work, but the physics can be tested): http://i-am-error.driehoogvoor.nl.

Way cool!. Although hard to progress, the proto looks like a great idea to implement in MSX.

Por hit9918

Prophet (2921)

Imagen del hit9918

16-08-2014, 15:45

Just a player and a scroller, there is no time problem.

And the collision detection with the ground is a different thing.
The pointerarray is for sprite hordes. For ground test, just look up your location in the level map. Which I called "software nametable" in the other post.

If you could afford twice the tiles in ROM, you could have a copy of the whole charset, but there the colors mean collision information.
You got 16 colors to make meaning like "here you can go", "here you get halted", "here you die".

So, the level map contains pointers to the tile graphics.
Adding a constant offset to that address there would move over to the collision info.
Maybe it could be done with just a flip in ROM mapper.

The webgame didn't work in my browsers, I see nothing, no idea what it's about.
And I don't know which tools you use to paint the charset.
Coding wise it is no ado to use the 16bit tile numbers for big graphics, more masses than usual 8bit game.

Well level map sizes. How big will it be. 10 screens cost 7k in 8bit and 14k in 16bit.
With 8x8 pixel chars, there are 768 chars in a screen.

Por Grauw

Ascended (10565)

Imagen del Grauw

16-08-2014, 16:37

@hit9918 I generally just use the top 4 bits of the pattern number to indicate that collision information.

As for the game, it works in Firefox and Chrome at least. If you have noscript or an extension like that installed, you need to set an exception of course.

Por jltursan

Prophet (2619)

Imagen del jltursan

16-08-2014, 16:59

Quote:

The webgame didn't work in my browsers, I see nothing, no idea what it's about.

The first time you load the webgame it tooks a while and leaves you with only a white screen. Try to refresh page after a while.

Por hit9918

Prophet (2921)

Imagen del hit9918

16-08-2014, 16:59

About collision I am poking in the dark what are the requirements.
With 16bit addresses it would be a bit more ado to get at some upper bits. But no speed problem in this game.
When the nametable goes in software, one can do many different things.
In my MSX1 scroll, the 16bit pointer points not directly to the pixels but to a descriptor.
For speed there must be a translation byte right there. And with INC HL I get to the collision ID byte.

Por Driehoogvoor

Resident (52)

Imagen del Driehoogvoor

16-08-2014, 20:22

Haha, I wasted half my day trying to fix a bug that wasn't really there. I had some minor garbage in VRAM en then my MSX crashed, so I went bug hunting for hours. In the end, it turned out they were two separate problems... The crash was not settings the stack pointer to the map data, the VRAM garbage was because I was writing in the sprite data range, haha. Ah well, at least I can explain the bugs, so I learned something and that's all that counts. Smile

Anyway, here's the code:
http://driehoogvoor.nl/files/msx/scroll.txt

Thanks for all the help, guys. The code uses Hit9918's method for drawing the map data. The collision detection is going to be relatively simple (even though it'll probably still take me a while to build). I'll only have to check the player against the world. There's only one screen of map data, with lines being added on top and removed on the bottom.

As for the JavaScript game: like Jltursan said, it takes a while to load. The resource loader takes a while to finish (I should probably just remove the MP3 files for now…) and it shows a white screen while loading. What browser are you using? I'm coding in Webkit and even though there is some Mozilla support for canvas scaling, I haven't done any fallbacks for other browsers. In IE, probably nothing happens, as the code needs the Web Audio API right now, and IE only supports HTML5 Audio.

Página 2/3
1 | | 3