Home | Forums | What's new | Resources | |
Alundra port/clone |
surixurient - Jul 17, 2014 |
1 | 2 | Next> |
vbt | Jul 20, 2014 | ||||
nice project !
does it mean everything is scripted in one or more files and so it needs only a good interpreter to develop ? |
surixurient | Jul 22, 2014 | |||
yes definitely. |
surixurient | Jul 25, 2014 | |||
I'm starting to figure out the animation but I made a horrible discovery. many of the sprite bitmaps are not byte aligned, ie they are 4 bits per pixel and they start at odd x coordinates or have odd widths. That is kind of a disaster for my plan of using the original content. ill have to rejigger all of the sprite bitmaps and hope it doesn't introduce any new unwanted pixels at the edges. |
vbt | Jul 29, 2014 | |||||
maybe you have to round width by 8. i had to do that on sega system 1 driver. |
surixurient | Jul 29, 2014 | |||||||||
yeah ill need to extend widths of sprites to 8. currently i think I have the sprites mostly figured out and am trying to get further on event codes. I have identified what i call entities which have a position and other properties. usually they are npcs or monsters or buttons/switches/etc. each entity has 8 strings of event codes. one string is executed on map load, another when you touch the entity, another when you interact with the entity, another on each AI tick, etc. the problem is some entities are having strings of codes executing on them which are not one of their 8 strings, and i cant tell where those codes are coming from. i see them in the files but cant tell how they are being linked to the entities. |
surixurient | Jul 31, 2014 | |||
I guess sprites are not completely sorted out. there are issues to address with semi transparency and special effects. also there is some more to figure out with reversed sprites. My biggest roadblock is still events though. i can handle set animation, face player, launch dialog, dialog branching, but that's about it so far. here is my latest tool state http://oi59.tinypic.com/mrvbwk.jpg |
vbt | Aug 1, 2014 | |||||
your tool looks really good |
surixurient | Aug 4, 2014 | |||
I'm making a lot of progress on events now after discovering the logic flow commands. setvariable, if, ifnot, until, and jump. the logic branches and jumps explain where the mystery event codes were coming from, it jumped to them. |
surixurient | Aug 12, 2014 | |||
I've started on the saturn renderer now. unfortunately all of the graphics wont fit in saturn video memory. because I cant use the vdp2 for anything besides cloud shadows and stuff, im stuck with under 512kb of video memory and the psx game uses over 700kb. I'm not sure what ill do at this point, either try to identify and not load unused bitmaps or else load bitmaps on the fly when they are requested (for spells and attacks and stuff) |
vbt | Aug 13, 2014 | |||||
normally, it should be easier on saturn as PS1 has 1MB of vram and saturn 1,54M. as you display everything as sprite can't you use a part of the VDP1 framebuffer to get enough memory ? the other way is to use more the vdp2 but i guess you'll need more rework |
surixurient | Aug 13, 2014 | |||||
Im not sure how id use part of the framebuffer because you only have enough bits (when drawing a sprite) to specify an address in the 512kb range. I could maybe store extra sprites in the framebuffer and move them to actual vram once i need them which might be faster than moving them from workram? but dont saturn sprites use the framebuffer? i remember reading that they are not traditional sprites which are drawn when the monitor traces. There are a few things I can move to vdp2, like sprites i know will always be below everything else like animated water, cloud shadows that are always above everything else, and possibly the inventory menu and items, but I dont think anything else will work because its either maptiles which need to be sorted, or sprite animations and effects. even the font wont work on vdp2 because its variable width characters. The issue is that the psx game has way more stored in vram than it's actually going to ever render. But, its hard to say what can safely be left out and when it needs to come back. here is a breakdown of what is in vram: -all of the main characters animations and spells(some of which are only used a specific parts of the game or in certain cutscenes, but its always in vram) 7 256x256 spritesheets -inventory graphics 1 256x256 spritesheet -background or shadow graphics 1 256x256 spritesheet -menu and gui graphics 1 256x256 spritesheet -a font area also used as backbuffer for dialog 1 256x256 area those are always in memory then for each gamemap/level there are 0-5 256x256 spritesheets for sprites (usually its just 2, but some maps use all 5) 6 256x256 sheets for maptiles the last one is usually an 8 frame animated sheet like water so its up to 22 4bpp sheets in total |
surixurient | Aug 19, 2014 | |||
I'm documenting some stuff here in this thread that I can refer to in email communications. Event Entities
Example Event Programs These are some event programs
Dummy entities(0-5) related to the overhanging crows nest Dummy entity(10) next to the bird used for a camera pan |
vbt | Dec 20, 2014 | |||
surixurient, any news about your nice alundra project ? |
surixurient | Jan 7, 2015 | |||
Well I got sidetracked for a long while playing a certain mmorpg. Now I am back to converting some of the game functions to c code. I am trying to automate as much of the conversion as possible, so im developing a MIPS disassembler and i create symbols for it as i am able to identify them. |
mrkotfw | Jan 8, 2015 | |||
Don't copy from VDP1 VRAM to VDP2 VRAM. Things are going to have to be a little different than on the PlayStation. You need to decide what needs to be a sprite and what can be considered a background. In other words, whether to use the VDP1 or VDP2. I would suggest you keep the font, inventory, shadow, sprite sheets graphics on the VDP1 and the rest on the VDP2. Depending on how many backgrounds you need, you can probably designate a background for the menu. Depending on how many sprites you need on screen at once, you can probably get away with keeping everything in memory. On the Saturn, the commands sent to the VDP1 are stored in memory. What library are you using? SGL? SBL? As for the sprites being unaligned, that should be fine. If you use the VDP1, you can copy one sprite, then calculate the address for the next sprite to be on a 8x1 (4-BPP) byte boundary (4-byte boundary) by rounding up. That's the smallest a texture can be. This way, you can still keep the original data untouched. |
Wesker | Apr 8, 2015 | |||
How is this going along? Really interested in the possible outcome of such a monumental effort like this. It would certainly be a fantastic game for the Sega Saturn. |
SloppyStone | Nov 30, 2016 | |||
I too, would like to know how this project is doing... I've never owned or played a Sega game but am a huge, HUGE fan of Alundra and this gets me very excited. Been lurking this thread for a year now in shadows. DONT give up! Or at the very least, release your awesome tool to the public, lol |
1 | 2 | Next> |