Grauw’s RPG in development

Por PingPong

Enlighted (4138)

20-03-2018, 07:58

Hey grauw are you using hw sprites?
the !ain char look more like a sw one ?

Por Grauw

Ascended (10768)

20-03-2018, 08:45

wyrdwad wrote:

As someone with absolutely zero technical knowledge, what does this mean, exactly? Does this mean the game won't be playable on my base Japanese MSX2+ without an add-on card?

It will be, I was only discussing the idea of additionally supporting V9990 for older MSX generations, but it's too much work for this project.

PingPong wrote:

Hey grauw are you using hw sprites?
the !ain char look more like a sw one ?

I drew it in full colour (with up to 16 colours), but it's using 8 hardware sprites to display, two stacks of 4 OR sprites layered. Software sprites are a bit annoying when the screen scrolls, worst case you need to split the copy into four parts if you're on both the horizontal and vertical edge of the scrolled bitmap.

I could go through a lot of trouble to try to rearrange the colours so that it could work with 2 or 3 OR sprites, but this is easier, and I can still display 4 more sprites horizontally, should be plenty for those rain and other particle effects.

I will not use hardware sprites for all characters though, NPCs will generally be drawn as tiles, lighter than softsprites but not challenging the sprite limits.

Por DarkSchneider

Paladin (1020)

20-03-2018, 08:45

Grauw wrote:

No… I did consider adding V9990 support for MSX1/2 users, but I dropped that idea to keep the scope down. It will work on MSX2’s with VDP replaced by a V9958 though.

What was a great idea. The V9958 is very underused to feel the need of V9990.

Por wyrdwad

Paladin (934)

20-03-2018, 13:22

Manuel wrote:

What kind of add on card are you thinking of?

That's what I was asking! Grauw said "It will work on MSX2’s with VDP replaced by a V9958 though." I don't know what V9958 is, but I assumed if some component (I assume VDP is short for video display processor?) is being replaced with it, then it must be some kind of add-on card or something.

It sounds like that's not the case, though! Thanks for the response. I look forward to checking this out anew, now that I know I probably will be able to.

-Tom

Por Grauw

Ascended (10768)

20-03-2018, 14:48

Ah, I can see how that would look like a strange code language . Let me try to clarify...

The video display processor (VDP) of the MSX2 is the Yamaha V9938. The VDP of the MSX2+ is the Yamaha V9958. The Graphics9000 extension cartridge has the Yamaha V9990. Some people have modified their MSX2, upgrading the VDP to a V9958, so they can run certain MSX2+ games.

So what I was saying is, my game is for MSX2+ computers and turboR, but it will also work on MSX2’s where the VDP has been upgraded. Additionally, I considered supporting the Graphics9000 cartridge’s VDP, but it’s quite different so it would cost too much time to support for this project.

Por wyrdwad

Paladin (934)

20-03-2018, 16:07

Ahh, OK. I didn't realize the 2+ actually had a different video display processor than the 2! That's really interesting, and seems like something fascinating to look up in more detail when I have a bit more time.

Thanks for the clarification!

-Tom

Por Grauw

Ascended (10768)

20-03-2018, 19:47

wyrdwad wrote:

Thanks for the clarification!

Yeah, the VDP is the only real upgrade of the MSX2+ compared to the MSX2. It’s a fairly minor upgrade too, but it adds two useful features (and a few not so useful ones):

Hardware horizontal scrolling: This feature is important for games. On MSX2, vertical scrolling is easy but horizontal scrolling is tedious and consumes quite some CPU and VDP power, especially in screen mode 5 and up. There are a few MSX2+ only games like Greatest Driver and Laydock 2. Other games work on MSX2, but get a graphics and / or scrolling upgrade on MSX2+, such as Golvellius 2 and Space Manbow.

Two YJK screen modes: This feature is mostly important for home users. Primarily aimed at digitised pictures, they can display up to 19268 colours (as opposed to 512 on MSX2). Good for people to make slideshows with, and for video editing, though no MSX2+ video computers were released. Some games show digitised images if they detect the presence of an MSX2+, e.g. Golvellius 2 and Laydock.

All in all though, in the total games library for MSX, there aren’t many that use the MSX2+ capabilities.

The reason this game is for MSX2+ is that I use the horizontal scrolling feature, so that I can scroll at the 2 pixel per frame speed, and also so that I’ll have CPU and VDP power left to do other things like showing nice animations and effects, and make my life easier in general (and give the MSX2+ some love). If I’ve got time left I might sneak in some YJK screen mode use as well, but don’t count on it .

Por Manuel

Ascended (19469)

20-03-2018, 19:38

I like that in Quinpl and Nyancle Racing Extra nice images on MSX2+

Por FiXato

Scribe (1743)

20-03-2018, 20:48

Good to see another non-combat RPG.
Might be an interesting related watch: Non-Combat Gaming - How to Make Social Mechanics Fun - Extra Credits

And for RPGs in general: What Makes Us Roleplay? - Why Game Worlds Feel Real - Extra Credits

Por Grauw

Ascended (10768)

27-03-2018, 20:51

I read a nice thing here:

引用:

In Contra, everything happen in screen space. The positions of the players and the positions of the enemies and bullets are all stored and manipulated within the coordinate system of the screen (i.e. a position of 0 always means the point in space that is currently at the left side of the screen, no matter where within the level the screen has scrolled to.)

This is an optimization that seems a little counter intuitive at first because you would think that storing all of your positions in screen space would make things like scrolling a lot more complicated. Now instead of just changing a single scroll position variable to scroll the screen, you have to manually move the positions of every enemy, player and bullet every frame to simulate scrolling.

The reason that this actually ends up being a good thing to do is that it saves a lot more time than it costs each frame. Scrolling is more complicated, but it really just boils down to adding 1 extra number into an object’s position as it updates each frame which is often just 1 extra CPU instruction per game object.

The big win is that now all calculations related to the positions of things can be done using 8-bit values (the NES screen is 256×240 pixels so you can locate any position on screen with pixel precision using a single byte for X and Y.) Since the NES only supports 8-bit arithmetic natively this ends up being way faster than trying to emulate 16-bit arithmetic to handle 16-bit world positions.

I did just a minimum effort experiment, and it already reduced the frame time of my player collision detection from 7.14% (1.19 ms) to 6.35% (1.06 ms). If I fully rewrite it with 8-bit rather than 16-bit coordinates, and introduce a local collision map, I think I can halve the execution time, due to using cheaper instructions, fewer memory accesses, and having more free registers. So, I think it’s a nice tip!

Conceptually, it helps me to think of the map like a big moving platform which the player and other objects are attached to.

This local map is another idea, a small 16 by 16-tile view on the entire tile map in an aligned circular RAM buffer. With this I can make a lot more assumptions in my code about the size and location of the data I’m using to display and collide with. As it moves around, the buffer is populated with the new tiles that appear on screen.

When objects and tiles appear on the local map they get a notification, when they move off screen they get another. If a tile’s image or collision changes depending on conditions like time or game state, they can update themselves in the registration notification, or register for a tick callback, etc.