Release Planet Hively


Magic Sam

Forever Homebrew
Joined
Aug 10, 2007
Messages
2,535
Age
41
Location
Dogs in Space !
Hi all :)

I have compiled Planet Hively on the Pandora, a music disk from Iris and Up Rough, released in 2007:

00049931.png


http://www.pouet.net/prod.php?which=49931

https://github.com/pete-gordon/planet-hively

Grab it on the repo while it's hot !

http://repo.openpandora.org/?page=detail&app=planethively-magicsam

New in build 1:

- Planet Hively (last git commit from January 12, 2016)
- Compiled with @ptitSeb 's latest Code::Blocks
- Source code is inside the package

Cheers, Magic Sam
[doublepost=1493907781,1493890770][/doublepost]Hi again,

While I'm at it, I gave Hively Tracker a go this afternoon:

http://www.hivelytracker.co.uk/

https://github.com/pete-gordon/hivelytracker

The SDL port compiles correctly, but it segfaults when playing a MOD file.

I need to investigate further...

Cheers, Magic Sam
 
Thanks, this works fine on my GHz machine and is a novel interface to a music disc, with some cool sounds. Sounds like I'd like to have a play with the tracker that made this music, but take your time in getting that working.
 
Hi all :)

Sorry for the delay...

I recompiled Hively Tracker with @ptitSeb 's latest beta Code::Blocks and debugging symbols, then ran it with gdb:
Thread 1 "hivelytracker" received signal SIGSEGV, Segmentation fault.
0x400d3054 in SDL_UpperBlit ()
from /mnt/utmp/codeblocks/usr/lib/libSDL-1.2.so.0
(gdb) bt
#0 0x400d3054 in SDL_UpperBlit ()
from /mnt/utmp/codeblocks/usr/lib/libSDL-1.2.so.0
#1 0x0001384c in bm_to_bm (src=0xca928 <about_bm>, sx=-4, sy=-4,
dest=0x61f4c <mainbm>, dx=236, dy=176, w=328, h=248) at ../gui.c:683
#2 0x0004cfd4 in about_handler (gotsigs=0) at ../about.c:506
#3 0x00012c14 in main (argc=1, argv=0xbeffe884) at ht.c:126

Do you guys understand what's going wrong ?

Cheers, Magic Sam
 
My vote goes towards that being a buffer overrun. You're passing in a source of destination pointer in gui.c which presumably point the the start of defined buffers, and if the destination one isn't big enough it'll do this. Or the pointers could be simply invalid, pointing to a read-only part of the memory map or something.

Why this happens on Pandora and not on other platforms would need more investigation though. Maybe it's to do with the way the GPU works by writing back to the framebuffer in main memory, rather than maintaining its own framebuffer, but that's just a guess. Do you know what platforms it is successfully running on already?
 
Hi all :)

Sorry for the delay...

I recompiled Hively Tracker with @ptitSeb 's latest beta Code::Blocks and debugging symbols, then ran it with gdb:


Do you guys understand what's going wrong ?

Cheers, Magic Sam

I don't know if its related to this but searching on the net i found this https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=184437
Don't have time now to test, but if you could ...try loading a mod file (instead of a lively tracker mod) with only 4 channels did segafults or not the tracker, if segafult maybe its related to a SDL_mixer bug.
 
Hi all :)

Sorry for the delay...

I recompiled Hively Tracker with @ptitSeb 's latest beta Code::Blocks and debugging symbols, then ran it with gdb:


Do you guys understand what's going wrong ?

Cheers, Magic Sam
It crashes in SDL bundled in codeblocks, does it also crash with the system SDL ?
 
Hi all :)

@Farox : thanks for the hint, I'll have a look at it ASAP !

@M-HT : yes, it does crash with both codeblocks and stock SDL.

Cheers, Magic Sam
The issue is "just" that SDL cannot get a buffer as small as the traker wants. And no check is done to see if the wanted buffer is exactly obtained.
To fix, simply change line 75 of replay.c
from
Code:
#define OUTPUT_LEN ((FREQ/50)*2) /* Linux can't cope with buffer being too small, so we sacrifice GUI responsiveness... */
to
Code:
#define OUTPUT_LEN ((FREQ/50)*4) /* Linux can't cope with buffer being too small, so we sacrifice GUI responsiveness... */
And it will not crash anymore. But there maybe so other place to adjust this *2 to *4, I'm not sure (and I haven't checked)
 
Last edited:
Hi all :)

@ptitSeb : you are, as always, right ! Thanks a lot :D The sound quality is weird though, compared to, say, Hively Tracker 1.6 running on MorphOS. It sounds like the tune is played a bit too fast...

I need to investigate some more before pushing a PND to the Repo.

Cheers, Magic Sam
 
Hi all :)

@ptitSeb : you are, as always, right ! Thanks a lot :D The sound quality is weird though, compared to, say, Hively Tracker 1.6 running on MorphOS. It sounds like the tune is played a bit too fast...

I need to investigate some more before pushing a PND to the Repo.

Cheers, Magic Sam
Yeah, I guess the difference between the buffer size between wanted / granted make things a bit wrong. I tried a few trick to compensate, but none were successfull in term of audio quality (but I may have made a mistake somewhere, I didn't kept the experiments anyway)
 
Back
Top