Or Screen 3 (1 pixel=4x4pixels). I've been planning something like that (just started to make some numbers, nothing serious), and if he wants to make something colorfull, it's the only way... refreshing the hole screen 2 or 4 will take some frames, but precalculate hi-res triangles will be a hell. Using Screen 3, you only have a 64x48 dot matrix so things will go speedier (but the display quality is lower)... perhaps it could be done hi-res, but I think then monochrome is the best option... and surely not rendering the whole screen but 2 banks only or so...

I recommend the spectrum game "The Dark Side" as a starting point:

www.ysrnry.co.uk/articles/thedarkside.htm

That "Freescape" engine by domark does some polygon thing, but depending on the number of poligons in the actual view the game goes slow... altough it's monochrome and the stage render is reduced to nearly half the screen...

screen 3 is a huge pattern-mode style .. you can't do typical bitmap operations to it without converting the pixels to the way they'll be put on screen.. and that's the sucky part, a real bottleneck!

True, Wolf_. But if you want it colorful i think it's the best solution, even if you must filter everything before VDP output. The hard things for a project like that -I think- are calculating 3D>2D and generate the pre-buffered display...

Quote:

Quote: Quote: - BASCOM This is not a compiler. This is a few bytes long program, that uses BASIC ROM to execute a single BASIC command from MSX-DOS. I also heard about a real BASIC compiler with that name, made by ASCII. Can anybody confirm the existence of this compiler or should we all just refer to the tool using BASIC ROM to execute a BASIC command from MSX-DOS?

Indeed, there is also a real compiler with that name, I have it. You need BRUN.COM to run the files and some library file iirc.

With the BASCOM you're referring to (or was it called BASKOM?) you could type Basic commands in DOS like BASCOM COLOR 15,0,0...

~Grauw

Quote:

So you're trying to make a Wolf3D-like game for MSX? <*snip*> The walls of your game will be textured, will be filled with a plain color or will have wireframe-like render?

Wolf3D doesn't use texturing.

Quote:

Enemies will be sprites?

Wolf3D's enemies are sprites too

Quote:

Your character will move in axis z and x, or will use y for jumps or climb to upper levels?

Wolf3D is a strictly 2D game that uses no real 3D, it's all raycasting. AFAIK you can't jump, there are no higher levels.

Quote:

In simpler words: how the hell are you going to planify the development of such a game? . I'm surely interested!.

So, provided you can do raycasting quickly on a MSX (I think it should be possible to do raycasting on a pattern basis, in stead of on pixel basis) Wolf3D isn't that hard.

What would be harder is Doom, which does use polygons and texturing, does have higher levels, does have jumping. But even Doom is still largely a 2D game with a 3D presentation.

David Heremans from Compjoetania TNG and openMSX wrote this tutorial on writing a Doom engine for MSX: http://msx.gnu-linux.net/doomlike/doomlike.html

I think that a tile (8x8) based ray-casting system will do it. If you are able to move it really fast (50/60 FPS) and use a wise tile-redefinition technique, then you can have a visually impacting thing going on.

Talking about implementation...

MSX1, Screen 2. The game would take the upper half of the screen. The bottom half would be for a cool game panel. The game should be rendered in 4x1 pixels blocks (or even 4x2). Enemies will be visible if defined in low resolution (lemme say, 16x16 pixels that would be magnified). I think the game should be entirely rendered in a memory buffer (about 3 Kbytes) and then dumped on screen. Floors and ceiling would not be rendered (just like Wolf 3D). The game would not render walls that'd be too far.

If I could run it in at least 15 fps, then I'd only have to put a good music and a good gameplay to be a very cool game.

By the way, I'd love to see an F-Zero like game for MSX 1 too...

Oh, even better for a Wolf 3D, the game could use a "Zanac-like" layout. Game screen at left (3/4 of screen) and at the right the game panel (1/4 of screen). Since the game would be rendered in vertical stripes, it'd be way faster.

Quote:

By the way, I'd love to see an F-Zero like game for MSX 1 too...

there's an F-Zero game for msx turbo R called F-Nano 2

4x2 would be useful because that gives 256 different (monochrome) possibilities per 8x8 area - exactly the number of patterns available. Furthermore, in screen 4 or 2 it is practical to use the upper 128 lines for the game, and the bottom 84/64 lines for the status region. This because the screen is actually divided in three pattern regions, each 64 lines (8 tile rows) high, which can all have a different pattern table base address (iirc).

The buffer for one screen stored like this would be only 512 bytes.

~Grauw

Quote:

In simpler words: how the hell are you going to planify the development of such a game? . I'm surely interested! So, provided you can do raycasting quickly on a MSX (I think it should be possible to do raycasting on a pattern basis, in stead of on pixel basis) Wolf3D isn't that hard. David Heremans from Compjoetania TNG and openMSX wrote this tutorial on writing a Doom engine for MSX: http://msx.gnu-linux.net/doomlike/doomlike.html

Interesting document... how is possible that no one did it before in MSX if it's "simple" and "possible" -even a demo-?... wow I see a lot of calculations there, would be a hell to code a game like that in assembler!.

Quote:

MSX1, Screen 2.

I like this requirements. Just cool

Next MRC Challenge: Maze Challenge?