Beta Zelda ... Kind Of

[sebt3]

This is just a small shot in the dark, but could timidity be to blame, I've noticed pickles is having some weird crashes associated with some of his ports that use it also... maybe if somebody has the old timidity-less version to give a test with, might prove useful

This sound like it :
- the original work don't have this freeze (which somehow rule out the original code)
- the scalling code I use is dumb, but it seems to work (no one complained about crash for ketm, and 140 downloads)
- thanks to naples39, my control edit have been ruled out

So here is a version without timidity : http://sebastien.huss.free.fr/pnd/Zelda3T_US.pnd

I would be glad if someone test this and repport.
I'm hopping for the best, because I have digged the source as far as I can and I'm basically clueless.
Else the sources are there : http://sebastien.huss.free.fr/pnd/Zelda3T_US-src-linux.tar.gz

 

[naples39]

So far so good with the newest, non-timidity version.

And yeah, I haven't spent much time with ketm, but didn't see any freezes otherwise.

 

[neko]

The no-timidity version seems to be working fine for me.

 

[sebt3]

Before I forgot : THANKS a TON Hooka

Why not use SNES layout?
F1 = select
Quit game = Escape/q
enlarge = f
item selection = start
confirm = b
select item = x
use item = a
sword = x
pickup/throw = b
talk/read = b
map = y
look around = left shoulder

I do have a few problem with this layout :
I don't want to mess too much with this part of the code (remember that I'll need to do it to 5 others codes). I cannot copy my edit from one game to the others (was the origin of the fast freeze in ROTH). So I want to stick with remplacement (sed for the win). That does mean that I cant split actions if they were using the same key.
With that in mind I tried to rework my remplacement : (the SDLK_* are the actual keymapping in the code)

SDLK_RETURN = confirm / pass text / item selection = start = SDLK_LALT
SDLK_ESCAPE = Quit game = Escape/q = SDLK_ESCAPE
SDLK_SPACE = read / open / speak = b = SDLK_END
SDLK_LCTRL = look around = left shoulder = SDLK_RSHIFT
SDLK_F1 = F1 = select = SDLK_LCTRL
SDLK_x = use item = a = SDLK_HOME
SDLK_w = sword = x = SDLK_PAGEDOWN
SDLK_LSHIFT = run = ???
SDLK_p = map = ??
SDLK_c = pickup/throw = ??

I could use already used key for pickup/trow (as you suggested B ), but I do share your fear about that (it might worth a try anyway)
If I don't use B for pickup, I'll want to use (Y), but then I cannot use it for map.

And finally, (once you get the boots) you have the hability to run, which key should I use for that ?

Once I get a good feedback about that I'll implement that in 3T (with may be a surprise if I manage to get this working).
Once I got good feedbacks about that (hopefully final) release, I'll do all this for the others 5.

Sound fair enough ?


EDIT transform a B) into a B )

 

[God Ginrai]

And finally, (once you get the boots) you have the hability to run, which key should I use for that ?

On the SNES, it was A (the right button) So you would use the Pandora B Button.

EDIT: Just to clarify the LttP controls for you:

   /\                                                                     /\
  /__\===================================================================/__\
 /\  /\ VI       S E C T I O N   S I X  |  C O N T R O L S           VI /\  /\
/__\/__\===============================================================/__\/__\


The controls of the game are simple, but here they are for you below, just in 
case you need a point of reference. If you've read any of my 23 other FAQs on 
GameFAQs, especially any of the 20 I have for the NES, you'll notice I have an 
ASCII art NES controller to go along with my control descriptions, for good 
measure. However, I'm not -that- talented, so I have no ASCII art for the more 
compicated SNES controller. =P Here we go. (word for word from The Legend of 
Zelda: A Link to the Past instruction manual, page 13, (c) 1991 to Nintendo).

Control Pad - Player Movements
------------------------------

With the control pad you can move your character in eight directions including 
up and down stairs. This also moves the cursor.

SELECT Button - Ending a Game
-----------------------------

The SELECT Button lets you end the game and save data.

START Button - Selecting Items
------------------------------

Press the START Button to switch to the Sub Screen. You can then select items 
to be used with the Y Button or check the status of your equipment.

X Button - Viewing the Maps
---------------------------

Press the X Button to view th overworld map or the dungeon map.

A Button - Holding and Running
------------------------------

The A Button can be used for a variety of actions, including picking up 
objects, running, talking, swimming, reading, grasping, and opening chests.

B Button - Swinging the Sword
-----------------------------

The B Button lets you swing the sword to attack enemies. This button also 
confirms choices made on the Player Select screen and Game Over screen.

Y Button - Using Items
----------------------

The Y Button activates various items for attack, defense, magic and movement.

This is from this FAQ: http://www.gamefaqs.com/snes/588436-the-legend-of-zelda-a-link-to-the-past/faqs/17687


-God Ginrai

 

[EvilDragon]

BTW: The WIZ port also seems to suffer the freezing bug.

Looks like there is something wrong with the game itself :/

 

[sebt3]

BTW: The WIZ port also seems to suffer the freezing bug.

Looks like there is something wrong with the game itself :/

Sure ? We have 2 users that don't have the freezing bug since I removed the timidity data-files.
I just suspect that We are bundling an realy old timidity set that no distribution ship anymore.
I'm planning try to use the big set (way larger )

 

[Shin-NiL]

BTW: The WIZ port also seems to suffer the freezing bug.

Looks like there is something wrong with the game itself :/

Hello guys!

I'm porting this game to Dingoo A320 (as you can see here) and we are having the same problem too :blink: I was looking in google for a possible solution and I found this post.

I've disabled sound completely, pulled out all the functions of SDL_image and converted to bitmap all images to use only SDL_LoadBMP, but the problem persisted. I have no more idea how to solve the problem.

I ran a top via telnet and the process appears with status "D." Any tips? Perhaps we are facing the same problem.

Thank you very much.

 

[God Ginrai]

BTW: The WIZ port also seems to suffer the freezing bug.

Looks like there is something wrong with the game itself :/

Hello guys!

I'm porting this game to Dingoo A320 (as you can see here) and we are having the same problem too :blink: I was looking in google for a possible solution and I found this post.

I've disabled sound completely, pulled out all the functions of SDL_image and converted to bitmap all images to use only SDL_LoadBMP, but the problem persisted. I have no more idea how to solve the problem.

I ran a top via telnet and the process appears with status "D." Any tips? Perhaps we are facing the same problem.

Thank you very much.

I would suggest looking through sebt3's source for his port to see what differences there are between your code and his. I would assume that this is the source that sebt3 used that does not have the bug:

Else the sources are there : http://sebastien.huss.free.fr/pnd/Zelda3T_US-src-linux.tar.gz

-God Ginrai

 

[sebt3]

I would suggest looking through sebt3's source for his port to see what differences there are between your code and his. I would assume that this is the source that sebt3 used that does not have the bug

Well, this package is also available on the original site and is nearly the original source.

 

[God Ginrai]

I would suggest looking through sebt3's source for his port to see what differences there are between your code and his. I would assume that this is the source that sebt3 used that does not have the bug

Well, this package is also available on the original site and is nearly the original source.

Yes, but I assumed he was making his port from the original code and was getting the freezing error. Which means that he already has the original code to look at. However, looking at a successful port might help him figure out what he should or should not be changing.

-God Ginrai

 

[sebt3]

Sure ? We have 2 users that don't have the freezing bug since I removed the timidity data-files.

I want to add my own report : 6 hours without freezing. The frezing was relatated to timidity.

Yes, but I assumed he was making his port from the original code and was getting the freezing error. Which means that he already has the original code to look at. However, looking at a successful port might help him figure out what he should or should not be changing.

The original source is fine.

@Shin-NiL : If you started from my source for roth, I added a freezing bug. Start from Vincent source instead. Sorry about that.

 

[EvilDragon]

So, using a more recent timidity version should fix the freezing?
That would rock

I'm still eager to play these games - but not without music

 

[God Ginrai]

Yes, but I assumed he was making his port from the original code and was getting the freezing error. Which means that he already has the original code to look at. However, looking at a successful port might help him figure out what he should or should not be changing.

The original source is fine.

I realize that. I am saying that if he has had the original source and ran into this error, he somehow introduced it on his own. And seeing as how he hasn't figured out what the error is from looking back at the original code, which I assume he would have done to try to find the bug, then looking at your code should help him figure out where the bug might be in his code.

-God Ginrai

 

[sebt3]

So, using a more recent timidity version should fix the freezing?

I'll leave a note here as we are now 3 working on these games

Most (to not say all) linux distribution now only ship freepats as timidity datafiles. The original timidity datafiles (we are all using as they are half the size) may now trigger an obscure bug in timidity or SDL. (Wild guess)
I plan on trying them within the weekend to see if it work.
The file size might not be a real problem on pandora if this finaly happen.
If that isn't enough then I'll go on the tracker route converting all the midi files to Impulse Tracker format (SDL does support that through mikmod) using Modplug Tracker (first experience ever).

But for now, I just want to track down that nasty bug that drive the game to segfault if the sound card isn't available (let's say I want to listen Metallica while playing ). But I'm not surprised as the code don't handle this And I want to have good control not there yet (thanks God Ginrai for the reference).


@Shin-NiL & @hmn :
We should share our work on this don't we ?
I would like having a cleaner code (a struct containing control definition should be better than having to do our hardcoded changes is the first thing that come to my mind, I do have many more...)


Cheers,
Sebt3

 

[God Ginrai]

If that isn't enough then I'll go on the tracker route converting all the midi files to Impulse Tracker format (SDL does support that through mikmod) using Modplug Tracker (first experience ever).

+1. IT files are great and Modplug Tracker is a great program. I'm pretty sure the MIDI format is just screwed up in general. I remember it was always encouraged to use Impulse Tracker Music in OpenZelda because midi sometimes caused the application to crash or freeze or something like that.

-God Ginrai

 

[Shin-NiL]

Hello guys!

I'm using the original Linux source code as a starting point. Actually I just removed the scaler, because the Dingoo resolution is 320x240, and remapped the buttons. I disabled the sound, because I thought that mid files were causing the problem, but in fact, the version without sound just takes longer to freeze.

Today I started looking in the code for possible causes of memory leaks, I found some problems and now I'm looking for more. I believe this may be the cause of this bug, and as Dingoo is what has less memory (32MB) is where the freeze happens with less playing time. Just a hunch.

@sebt3 Sure, we can share our work


Thank you very much.

 

[EvilDragon]

Today I started looking in the code for possible causes of memory leaks, I found some problems and now I'm looking for more. I believe this may be the cause of this bug, and as Dingoo is what has less memory (32MB) is where the freeze happens with less playing time. Just a hunch.

That would actually make sense - on a PC, it probably runs days before it runs out of memory.
With timidity, more memory is used up so the leak fills up quicker.

On the Pandora, you could check with top while the game is running if it sucks RAM

 

[Pleng]

I'm pretty sure the MIDI format is just screwed up in general.

-God Ginrai

The MIDI format has been used in pro music for, what, 30 years or more? I hardly thing the format can be 'screwed up in general'. If things are crashing because of midi playback then it's the process that's being used to decipher the file that's the problem, not the format itself!

MIDI really wasn't designed for games, anyway.

 

[God Ginrai]

I'm pretty sure the MIDI format is just screwed up in general.

-God Ginrai

The MIDI format has been used in pro music for, what, 30 years or more? I hardly thing the format can be 'screwed up in general'. If things are crashing because of midi playback then it's the process that's being used to decipher the file that's the problem, not the format itself!

MIDI really wasn't designed for games, anyway.

What I meant by screwed up in general is that no one has really ever given enough of a damn about it to create good support for it, and thus, those that try to use it run into problems because no one put in enough effort to get it fully right.

-God Ginrai