wolfenstein demo for sega genesis

[gasega68k]

cleeg, I made a rom test to find out where the error exactly occurs, for this I made the border color above and below (normally black) changes color depending on a specific part of the code (there are 8 colors) and when the error occurs, and by the color of the edge (top and bottom) I'll know where the error occurred.
Here is:
http://www.mediafire.com/download/gs8gz ... .3test.rar

[gasega68k]

I think I found where the error was. Now the option to select 6-button control should not cause it to hang.
Here it is (version 6.3b):
http://www.mediafire.com/download/xc2v1 ... _b6.3b.rar

cleeg, can you please confirm that no longer hangs?

[inu]

Shiny new update!
And of course, I ended up playing the hell out of it... again!

Some of the musics I made a little different , I download a lot of midis and mp3 , and some seemed to me it sounded better than the original and I did more similar to these (eg the song that plays on the secret level ) but most tried to make them as similar as possible to the original .

Well, I surely approve of all the choices, they all EASILY remind me of the original tracks.

The item pickup also feels slightly more reliable. I'm not sure if that was just me, as I'm getting used to the "right away" of grabbing stuff, or it was an actual change.
Funny as I used to think that item pickups were map-position related, but I now realize that it's actually related to what the character can see.

Also added routines for "palette shift", which is used when the player takes damage (shift to red) and when you grab an item (shift to white / yellow), I've also added the routine so that when the player dies, it turns to look at the attacker, I also corrected some errors that had mentioned inu, and by the way, I want to thank you for always being aware of the errors.

The flashing animations look surprisingly nice, especially with all the MD limitations. Grabbing items was fine before without it, but the "getting shot" flashing helps SO MUCH!
I'm glad I could be of ANY help to your project. I'll keep trying to "break" your W3D Mega Drive\Gen port and report anything I find.

I've also been trying hard to get my char stuck on other enemies and I only managed it once. So it definitely feels fine as it is, it was super easy to make it happen before.

Also I'd like to leave a very minor change to consideration, even tho it's still quite early to start fixing language related stuff. Instead of "Control", maybe go for "Controller" or maybe "Controls". What do you native English speakers think? xD


This reminds me that there might actually be something that the players can do to help if they have a bit of knowledge about it. The auto-played "Demo"s are still missing and at least the first one, where the character kills only the already implemented generic grunts could be "easily" replicated to look VERY similar to the original one, using TAS-like timed inputs.
The first Demo is at 0:48 - https://www.youtube.com/watch?v=iRMCPJDlIk0


EDIT 01:
Removed information about a certain "problem". It happened in Kega Fusion, but not on Bizhawk.
Exodus 1.0 doesn't seem to like the game much. Only the directional keys are working, so I can't really test it there.

[buricco]

Well, it's "Control" on the DOS version...

[inu]

Well, it's "Control" on the DOS version...

Yeah, but for example the option to actually change the buttons is called "Customize controls" (tested on the Free browser edition).
http://3d.wolfenstein.com/game_EU.php
This version has a few errors in the maps tho, so I'm aware it's not fully reliable for other things.

Also, computers were expecting a keyboard. Video game consoles are expecting a controller.
The Jaguar edition, for example, says "Controls".

Anyway, it's something so minor maybe it's not even worth changing in the end.

[ICEknight]

I'm really enjoying this game better with each version. Here's a couple of things I've noticed:
-You can't strafe diagonally.
-Grabbing the items requires you to step right on top of them.

Also, I've noticed that sometimes the screen can glitch for a frame (show some blackness in the play area), but either it's random or I haven't found a pattern to it. No idea if it happens on emulators.

Regarding the music, I think the closest it can be to the original PC game, the more "official" this will look like, which would be a very good thing in my oppinion. Some of the tracks I've heard sound amazingly close to the originals, so good job on them!


By the way, I can confirm that the latest version works in real hardware without hanging when choosing the 6-button pad.

[cleeg]

Yes, got it working too. I posted on Sega 16 and forgot to do so here too - Sorry!

[gasega68k]

Hello everyone.

The item pickup also feels slightly more reliable. I'm not sure if that was just me, as I'm getting used to the "right away" of grabbing stuff, or it was an actual change.
Funny as I used to think that item pickups were map-position related, but I now realize that it's actually related to what the character can see.

The way you grab objects is done in the engine to draw, if visible, if is in a specified distance forward, and in a given distance from the center to both sides, (these values can be changed), this is a very efficient way to test collision with objects, because this way is only tested the objects that are on screen, if it done otherwise, for example, comparing all positions (x, y) of the object relative to the player, it would be much more slow, there may be a total of 400 static objects!. Although perhaps there may be a more efficient way to do it.

Also I'd like to leave a very minor change to consideration, even tho it's still quite early to start fixing language related stuff. Instead of "Control", maybe go for "Controller" or maybe "Controls". What do you native English speakers think? xD

I could change it to "controls", just have to add an "s".

This reminds me that there might actually be something that the players can do to help if they have a bit of knowledge about it. The auto-played "Demo"s are still missing and at least the first one, where the character kills only the already implemented generic grunts could be "easily" replicated to look VERY similar to the original one, using TAS-like timed inputs.
The first Demo is at 0:48 - https://www.youtube.com/watch?v=iRMCPJDlIk0

To make an "auto-played demo", maybe I can use the file generated by an emulator, such as Gens movie, when we recorded and creates a "movie file" (. Gmv file), maybe I can use this file to create the "demo", I do not know, but before doing this, I would first make the other enemies and other things, such as end of level screen.

-You can't strafe diagonally.

I had not realized this, I know this did not happen before, so I tried previous versions and I realized that this happened from version 4 , earlier versions was fine, I have to fix this.

-Grabbing the items requires you to step right on top of them.

Maybe I could change this, so that the "area" where you can grab the Item, be larger.

Also, I've noticed that sometimes the screen can glitch for a frame (show some blackness in the play area), but either it's random or I haven't found a pattern to it. No idea if it happens on emulators.

You mean from the top? I saw this once when I tried it on real hardware, emulators seems that this does not happen.

By the way, I can confirm that the latest version works in real hardware without hanging when choosing the 6-button pad.

Yes, got it working too. I posted on Sega 16 and forgot to do so here too - Sorry!

The error of the 6-buttons was "very rare", but I'm glad that I have already solved.

I've been drawing the "SS" ("blue" guards) and dogs, plus I'll add the graphics option, to add some "filters" to enhance the image (for this I have to change some things), so soon I will be showing a new version with the SS and dogs and possibly the "filters".

[matheusbn]

The way you grab objects is done in the engine to draw, if visible, if is in a specified distance forward, and in a given distance from the center to both sides, (these values can be changed), this is a very efficient way to test collision with objects, because this way is only tested the objects that are on screen, if it done otherwise, for example, comparing all positions (x, y) of the object relative to the player, it would be much more slow, there may be a total of 400 static objects!. Although perhaps there may be a more efficient way to do it.

One way that would be nice since you are using 2D grid, it would add a flag to that cell containing the object's ID. After that you just need to check if there's an object alive when the player entering on that cell.

Since we are talking about a limited system, the cell should store both: Texture ID and Object ID.

PS: Sorry my english.

Matheus.

[gasega68k]

Hello, Matheus, welcome to SpritesMind.

Since we are talking about a limited system, the cell should store both: Texture ID and Object ID.

The game is made with maps of 64 x 64 cells or grids (called tiles in the engine) and there are several 4kb memory array ( 64x64 ) in the game: Tilemap: this contains the textures of the walls, Actorat: used for the collision with the walls and some objects (tables, barrels), Spotvis: This is used to find out which objects are visible, in addition to these, are also the two that are extracted directly from gamemaps.wlx file, from these two arrays are create the others mentioned above, and also made another array called actorat_objid to collision with enemies.

The static objects (tables, barrels , items, etc. ) and active objects (enemies) work differently, the static can only be in the center of a tile, and contain only a few variables (Tilex, Tiley, shapenumb, etc...) and active objects (enemies) can move freely and contain a large amount of variables (more than 26), there may be a maximum of 150 active and 400 static objects. In my engine, I intended 8kb ram for active objects (about 7kb were used, about 44-48 bytes per object) and for static 4kb (10 bytes per object).

One way that would be nice since you are using 2D grid, it would add a flag to that cell containing the object's ID. After that you just need to check if there's an object alive when the player entering on that cell.

The collision test with the enemies, is made that way, at least that's how I did it: There is a memory array (64x64) I call actorat_objid, where zero indicates no collision and a number from 1 and 150 indicates which enemy is on that tile, and that number is the id of the object, so when the player enters the tile, this will know if there is an object (enemy) there.
This can not be done for static objects at least not as active objects, because there may be more than one object in the same tile, for example when you kill multiple enemies and various ammunition remain in the same tile.
But anyway as I said before, the way that the collision is made for static objects, I think it is the best, because only the objects that are on the screen are tested.

PS: Sorry my english.

My English is not good either.

[matheusbn]

Hello, Matheus, welcome to SpritesMind...

Hi, gasega68k

First of all, I forgot to say that you're doing a great job on this port. Congratulations.

So based on what you said, I think I understood your design:

The game is made with maps of 64 x 64 cells or grids (called tiles in the engine) and there are several 4kb memory array ( 64x64 ) in the game: Tilemap: ... Actorat: ... Spotvis: ... actorat_objid ...

It's nice and I'm pretty sure that you had your reasons, but if you don't mind I would like to share/suggest another line of thinking:

So instead of 4 or more arrays, what you think about only 2?

Where:

Array #1 - Size 64x64 Storing both: TEXTURES and STATIC OBJECTS.

Array #2 - Size ~30 For enemies (Based on a structure x, y, isAlive, enemyID).

Because for what I remember well, the original game had about 20~30 enemies per level, so I think you can loop over it without too much cost. I would suggest the TaxiCab collision detection for speed up the checking.

...and active objects (enemies) can move freely and contain a large amount of variables (more than 26)...

Could you tell me why there are so many variables?

But anyway as I said before, the way that the collision is made for static objects, I think it is the best, because only the objects that are on the screen are tested.

But on the other hand when the player walks backwards or using strafe and is upon the object he will not pick it because is not visible right? - So putting the static object together with the texture like I said above, you'll only need to check the collision when the player change the cell.

Bye,

Matheus.

[Chilly Willy]

It's nice and I'm pretty sure that you had your reasons, but if you don't mind I would like to share/suggest another line of thinking:

So instead of 4 or more arrays, what you think about only 2?

Where:

Array #1 - Size 64x64 Storing both: TEXTURES and STATIC OBJECTS.

Array #2 - Size ~30 For enemies (Based on a structure x, y, isAlive, enemyID).

He used the arrays he does because that's what the game uses. You probably need to look at the source code for Wolf3D. The tilemap is 64x64 because that's how many tiles there are in a level. You use one 64x64x1 array for the tiles because that's all that fits in a byte. There is no other info that can fit with the exception of two flags in the upper bits used for things like doors because there are so many possible tiles. The static objects have their own 64x64x1 array since they also need a byte to tell which sprite to use in that tile.

The spotvis array is needed because you have to have an array that matches the level map (64x64x1) for the raycasting to use for rendering info.

Anywho, like I said, you might want to look over the source before deciding arrays can just be tossed out or replaced.

[matheusbn]

Anywho, like I said, you might want to look over the source before deciding arrays can just be tossed out or replaced.

Hi Chilly Willy,

Well, like I said above I understood his design and the reasons why it were chosen. I was just trying to give him some ideas for the item pick up problem that other user pointed out.

Yes in fact I looked over the source code sometime ago, and here is the part where many things related above is defined: https://github.com/id-Software/wolf3d/b ... C/WL_DEF.H

Code: Select all

extern	byte		tilemap[MAPSIZE][MAPSIZE];
extern	byte		spotvis[MAPSIZE][MAPSIZE];
extern	objtype		*actorat[MAPSIZE][MAPSIZE];

The thing is: if he is doing a close port, just like the original, then he is on the right way and there is nothing else to do except forget what I said earlier.

Again: I was just wanting to help with pick up problem and maybe see if the game "could" play faster (decreasing the array access).

Bye,

Matheus.

[Chilly Willy]

Again: I was just wanting to help with pick up problem and maybe see if the game "could" play faster (decreasing the array access).

Sorry if I sounded harsh - just trying to point out that most of the arrays are needed. Iffen I were trying to speed up object finding, I'd probably make a hash table based on one of the object parameters. That should be fairly small while being much faster than almost any search of an array, small or not.

[matheusbn]

Again: I was just wanting to help with pick up problem and maybe see if the game "could" play faster (decreasing the array access).

Sorry if I sounded harsh - just trying to point out that most of the arrays are needed. Iffen I were trying to speed up object finding, I'd probably make a hash table based on one of the object parameters. That should be fairly small while being much faster than almost any search of an array, small or not.

Hi Chilly Willy,

There is no problem at all. It was just different opinions about design/programming etc. Which I just respect even so because I don't know if what I said would be doable to do too.

Bye,

Matheus.