SpritesMind.Net

RE: Game release, Uwol - Quest For Money

SteveMartin — Thu, 18 Mar 2010 05:58:08 +0100

Author: SteveMartin
Posted: Thu Mar 18, 2010 4:58 am (GMT 0)
Topic Replies: 16

Very cool, this is a great port! I hope you don't stop here, you probably can find many other great games to port

RE: New Sega Genesis Emulator : Retrocopy

Shadow — Wed, 17 Mar 2010 12:40:56 +0100

Author: Shadow
Posted: Wed Mar 17, 2010 11:40 am (GMT 0) Subject: New version of Retrocopy 0.720 released!

Topic Replies: 6

Finally we can use new Retrocopy 0.720, fixed many bugs in emulation Mega Drive, also added new features like a auto save game, sound equalizer + many improvements

RE: DMA instruction from RAM

Shiru — Wed, 17 Mar 2010 10:30:35 +0100

Author: Shiru
Posted: Wed Mar 17, 2010 9:30 am (GMT 0)
Topic Replies: 2

In all the C I've seen source DMA is performed with usual code, without any RAM tricks. I did the same in the Uwol, it works on the real hardware (at least two units).

I recall I've read somewhere that the hang with DMA related to memory aligment (of calling code?).

Edit: found where I've read that, it was translator's note in russian version of sega2.doc, which was translated by HardWareMan.

RE: VRAM Breakpoints

Qjimbo — Wed, 17 Mar 2010 04:23:43 +0100

Author: Qjimbo
Posted: Wed Mar 17, 2010 3:23 am (GMT 0)
Topic Replies: 2

Wow... I actually already looked at KMod and assumed it wasn't there, and there it is tucked in "Debug..." on the Options menu. Thanks Can't quite figure out how to get the most out of Regens breakpoints just yet though, I can't see any kind of logging facility.

UPDATE: Issue solved through modifying the ROM

RE: DMA instruction from RAM

Charles MacDonald — Wed, 17 Mar 2010 04:14:52 +0100

Author: Charles MacDonald
Posted: Wed Mar 17, 2010 3:14 am (GMT 0) Subject: Re: DMA instruction from RAM

Topic Replies: 2

Ketsuban wrote:

However, I recall reading somewhere a discussion about a particular game which uses DMA transfers just fine, but doesn't use RAM at all. I wanted to find this discussion to make a note of it for my own code, but I couldn't find it at all.

Does anyone know what I'm talking about?

I'd like to know too. I've tried to reproduce the DMA lockup you'd otherwise get on a number of Genesis and Genesis-derived systems, but could never do it.

I wonder if the bug is specific to developer hardware (say when using DRAM carts or whatnot) or to very early versions of the chip. Perhaps it is a problem that can happen in theory, so Sega provided a workaround, but in reality the conditions that enable it rarely occur.

DMA instruction from RAM

Ketsuban — Wed, 17 Mar 2010 03:01:21 +0100

Author: Ketsuban
Posted: Wed Mar 17, 2010 2:01 am (GMT 0) Subject: DMA instruction from RAM

Topic Replies: 2

The Sonic games (and as I understand it many other games too) follow the advice given in sega2.doc to put the final command word into RAM when initiating a DMA transfer.

However, I recall reading somewhere a discussion about a particular game which uses DMA transfers just fine, but doesn't use RAM at all. I wanted to find this discussion to make a note of it for my own code, but I couldn't find it at all.

Does anyone know what I'm talking about?

RE: VRAM Breakpoints

Jorge Nuno — Wed, 17 Mar 2010 02:17:20 +0100

Author: Jorge Nuno
Posted: Wed Mar 17, 2010 1:17 am (GMT 0)
Topic Replies: 2

Gens Kmod does Vram DMA logging to a file, and regen has breakpoints on Vram RW activity, so I think you have to use them both to handle DMAs and 68k writes .

RE: Advice on the Art of Genesis level Building

Gigasoft — Tue, 16 Mar 2010 20:00:07 +0100

Author: Gigasoft
Posted: Tue Mar 16, 2010 7:00 pm (GMT 0)
Topic Replies: 14

For tile updates, you could transfer a manageable number of tiles every frame until you're done. Uncompressing can be done in the background when the game is idle. In an upcoming game I'm making, I switch to a background task that performs loading of world data whenever I'm waiting for the next frame, enabling seamless scrolling in a very large world. I used the same technique in a NES game (which was never finished) with splendid results. In both games, I have 4x4 screenfuls loaded at once.

Usually, level data is not based on individual tiles, but larger blocks composed of tiles (usually 2 by 2 or 4 by 4 tiles). This is also so in my game, where the result after loading is an arrangement of blocks made of 2 by 2 tiles. The world data itself is command based, where there are commands to draw floors, walls and other objects, and the objects can be placed freely without regard for screeen boundaries.

RE: Advice on the Art of Genesis level Building

MottZilla — Tue, 16 Mar 2010 19:30:51 +0100

Author: MottZilla
Posted: Tue Mar 16, 2010 6:30 pm (GMT 0)
Topic Replies: 14

eteream wrote:

dtech wrote:

Regarding reprogramming - challenge is everything!
To have large, interesting levels, you also need to reprogram the maps quite frequently and fast, usually involving decompression of some sort. This is a challenge, especially if a game is a fast scroller.

If it doesn-t involve decompresion, I think this is very easy, you online need to move 2bytes for each tile.

And I don't think you can use compression in this instant. Compression only works for large amount of data with a big package. I think what games do is unzip to memory the level-map at the beginning of it. Do you have an info about it?

On SNES with 128Kb of WRAM I was thinking about what you could possibly need all that RAM for in the average game. This came to mind. Compressing level data (or other background data or graphics data) and decompressing it into some free RAM so it can be quickly DMAed into place when needed. Genesis has 64Kb of RAM which is also quite alot. I would guess you've still got plenty of room to take a compressed level and expand it to a huge background table in RAM for quick DMAing.

In commercial games I've heard of compression techniques like a Tree system where you have your level made up of big blocks which are defined somewhere. Sometimes these big blocks are made up of smaller blocks that are defined elsewhere. Then with all of that you might use RLE or some other compression to get size down even more. I suppose if you only had a few of these "big" blocks or little blocks you could save data room by only using as many bits as you needed. I'm sure there are alot of ways to compress level data.

Even now with being able to have 4 megabytes of data for low cost, you still may want to use some compression as huge level data really can get HUGE.

RE: Advice on the Art of Genesis level Building

eteream — Tue, 16 Mar 2010 18:38:48 +0100

Author: eteream
Posted: Tue Mar 16, 2010 5:38 pm (GMT 0)
Topic Replies: 14

dtech wrote:

.
Reprogramming, however, is a relatively easy one - when some token is reached with the hero alone in the center on mostly only background visible and ground of some sort, engine updates specific blocks of tile data (that is used on the next part of the level), the ones, which are on the screen, stay intact. Games usualy have a slight hickup at that point (a freeze for a frame or two) and then does not allow you to go back (because graphics will be trashed up by new tiles). sonic2/3/knuckles do this stuff a lot and quite smoothly.

This is used in Contra. It-s by far the most impressive game, technically speaking. But I don-t found any other game that uses this tecnic (Comix zone may be...). Most of other games did: screeen-off, load all needed data for level, screen-on.

But, since (surely) data is compresed in Contra it tooks more than 2 frames, something near half second. This game used the explosion of mid boss to do this trick (character can-t move for a bit seconds), so I am not sure a game that uses compression can do that trick, and maybe without either compression...

Again, do you have more info?

dtech wrote:

Another extreme programming challenge is to make effective enemy/object engine - again, sonic2/3/K does this amazingly well. Challenge is to make it all flexible and fluent - that every object that enters the proximity space, becomes active and has it's own processing/interaction routine (form rom, shared for all enemies of the same type), yet have dynamically assigned context scratchpads (separate for every 'live' object), that hold objects behaviour/position/action/phase, and that all such objects are processed using a dynamically maintained list where such routine can terminate itself and remove from list (when, for example, enemy is killed and explosion animation is done and over) or suspend (or keep alve) if that object is important (boss doesn't disapper or stop operating when leaving frame).

Such engine allows almost interaction things to be handled in the same way (like it's done in sonic) - be it a wall opening from a button press or operating a pulleys or some mechanisms, bosses that can release more enemies, animated checkpoints, etc...

I find this thing, along with map update engine, to be the hardest points, but also most beneficial ones, when those are up and running Because creating detailed and ellaborate levels becomes a joy! As well as creating enemies, that can generate more enemies (even by just shooting) and interactive objects.

If you know C++ there is no challenge, it's the same! Well, I found collision detection (all to all mode) more interesting... simply MD can-t handle a 'for' inside 'for'... (order n^2)... or I'm doing things bad.

RE: aPLib decruncher for 68000

Shiru — Mon, 15 Mar 2010 23:29:48 +0100

Author: Shiru
Posted: Mon Mar 15, 2010 10:29 pm (GMT 0)
Topic Replies: 27

I've just released updated version of Uwol, with fix for major bug and few minor changes, and one of the changes was packer replacement. Now it uses aPLib with SyX depacker - it works faster, and in case of this game it also has better compression ratio.

RE: Game release, Uwol - Quest For Money

Shiru — Mon, 15 Mar 2010 23:27:33 +0100

Author: Shiru
Posted: Mon Mar 15, 2010 10:27 pm (GMT 0)
Topic Replies: 16

Thanks for the report, Txai, I've just uploaded fixed version (v1.1). It has some other minor improvements as well.

VRAM Breakpoints

Qjimbo — Mon, 15 Mar 2010 22:46:50 +0100

Author: Qjimbo
Posted: Mon Mar 15, 2010 9:46 pm (GMT 0) Subject: VRAM Breakpoints

Topic Replies: 2

Hello all,
I need a version of Gens (or any other emulator) that will allow me to log all VRAM reads and writes. I need to be able to start and stop logging with some kind of trigger/button too.

Does such an emulator exist or would any of you kind folk here be generous enough to make me one?

I'm working on an unused VRAM addresses table so this would be a big help for me.

Thanks!

RE: Advice on the Art of Genesis level Building

Chilly Willy — Mon, 15 Mar 2010 20:44:12 +0100

Author: Chilly Willy
Posted: Mon Mar 15, 2010 7:44 pm (GMT 0)
Topic Replies: 14

Actually, with current flash cards and emulators, you don't NEED compression. Look at the Sonic series - Sonic 1 is only 512KB, and Sonic 2 just 1MB. If you assume all compression gave an average of 4:1 (really high), both fit in a flash cart uncompressed without a problem. Compression was used initially to keep the size down when roms where still expensive. So unless you are shooting for Sonic 3 or better size, you don't really need to worry about compressing anything.

RE: Advice on the Art of Genesis level Building

dtech — Mon, 15 Mar 2010 20:06:50 +0100

Author: dtech
Posted: Mon Mar 15, 2010 7:06 pm (GMT 0)
Topic Replies: 14

(A short reply due to lack of time at the moment)

HINT and VINT - horisontal and vertical interrupt, realy work well on genny, in contrast to pc cga/ega/vga hell

Sonic3 and many other games use hint for water.

Regarding reprogramming - challenge is everything!
To have large, interesting levels, you also need to reprogram the maps quite frequently and fast, usually involving decompression of some sort. This is a challenge, especially if a game is a fast scroller. I remember playfield was programmable to 64x64 tiles and thus, when running around, that flayfield need to be updated off-screen for all the new stuff there is. Also handle the disapperaing and appearing enemies and their actions. This all is a hard part.

Reprogramming, however, is a relatively easy one - when some token is reached with the hero alone in the center on mostly only background visible and ground of some sort, engine updates specific blocks of tile data (that is used on the next part of the level), the ones, which are on the screen, stay intact. Games usualy have a slight hickup at that point (a freeze for a frame or two) and then does not allow you to go back (because graphics will be trashed up by new tiles). sonic2/3/knuckles do this stuff a lot and quite smoothly.

I think i could dig up my old tool sources that had quite a powerful optimiser amongst them, and maybe rework them for windows and any user interface (they were for DOS and x-mode graphics hahaha *scary*).

Another extreme programming challenge is to make effective enemy/object engine - again, sonic2/3/K does this amazingly well. Challenge is to make it all flexible and fluent - that every object that enters the proximity space, becomes active and has it's own processing/interaction routine (form rom, shared for all enemies of the same type), yet have dynamically assigned context scratchpads (separate for every 'live' object), that hold objects behaviour/position/action/phase, and that all such objects are processed using a dynamically maintained list where such routine can terminate itself and remove from list (when, for example, enemy is killed and explosion animation is done and over) or suspend (or keep alve) if that object is important (boss doesn't disapper or stop operating when leaving frame).

Such engine allows almost interaction things to be handled in the same way (like it's done in sonic) - be it a wall opening from a button press or operating a pulleys or some mechanisms, bosses that can release more enemies, animated checkpoints, etc...

I find this thing, along with map update engine, to be the hardest points, but also most beneficial ones, when those are up and running Because creating detailed and ellaborate levels becomes a joy! As well as creating enemies, that can generate more enemies (even by just shooting) and interactive objects.

Contra hard corps is an another example of extremely well programmed engine that does hell lot of tricks and everything combined in a solid piece of consistent code. Same about vectorman and well... many many other games