Sega Megadrive/Genesis development
https://gendev.spritesmind.net/forum/
Well, I surely approve of all the choices, they all EASILY remind me of the original tracks.gasega68k wrote: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 .
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!gasega68k wrote: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.
Yeah, but for example the option to actually change the buttons is called "Customize controls" (tested on the Free browser edition).buricco wrote:Well, it's "Control" on the DOS version...
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.inu wrote: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.
I could change it to "controls", just have to add an "s".inu wrote: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
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.inu wrote: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
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 4ICEknight wrote:-You can't strafe diagonally.
, earlier versions was fine, I have to fix this.Maybe I could change this, so that the "area" where you can grab the Item, be larger.ICEknight wrote:-Grabbing the items requires you to step right on top of them.
You mean from the top? I saw this once when I tried it on real hardware, emulators seems that this does not happen.ICEknight wrote: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.
By the way, I can confirm that the latest version works in real hardware without hanging when choosing the 6-button pad.
The error of the 6-buttons was "very rare", but I'm glad that I have already solved.Yes, got it working too. I posted on Sega 16 and forgot to do so here too - Sorry!
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.gasega68k wrote: 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.
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.matheusbn wrote:Since we are talking about a limited system, the cell should store both: Texture ID and Object ID.
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.matheusbn wrote: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.
My English is not good either.PS: Sorry my english.
Hi, gasega68kgasega68k wrote:Hello, Matheus, welcome to SpritesMind...
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:gasega68k wrote: 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 ...
Could you tell me why there are so many variables?gasega68k wrote: ...and active objects (enemies) can move freely and contain a large amount of variables (more than 26)...
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.gasega68k wrote: 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.
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.matheusbn wrote: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).
Hi Chilly Willy,Chilly Willy wrote: Anywho, like I said, you might want to look over the source before deciding arrays can just be tossed out or replaced.
Code: Select all
extern byte tilemap[MAPSIZE][MAPSIZE];
extern byte spotvis[MAPSIZE][MAPSIZE];
extern objtype *actorat[MAPSIZE][MAPSIZE];
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 wrote: Again: I was just wanting to help with pick up problem and maybe see if the game "could" play faster (decreasing the array access).
Hi Chilly Willy,Chilly Willy wrote: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 wrote: Again: I was just wanting to help with pick up problem and maybe see if the game "could" play faster (decreasing the array access).