The Dink Network

Reply to Re: Bugfixes for freedink on Linux

If you don't have an account, just leave the password field blank.
Username:
Password:
Subject:
Antispam: Enter Dink Smallwood's last name (surname) below.
Formatting: :) :( ;( :P ;) :D >( : :s :O evil cat blood
Bold font Italic font hyperlink Code tags
Message:
 
 
August 6th 2022, 08:25 AM
anon.gif
ghostknight
Ghost They/Them
 
I have made some further updates to the
freedink buildscript

and the
freedink (branch versioninfo) source

itself. The build script currently only works with the version in branch 'versioninfo'. I will get back to that later.

Along some minor bugfixes, there are two important changes. The first involves the soundbank bug. As written earlier, the problem is that the function 'SoundPlayEffectChannel()' already returns the value for the soundbank but 'playsound()' erroneously increments it again. After studying the source only found two locations where the return value of 'SoundPlayEffectChannel()' is used. First, in 'playsound()' and then in the file 'brain_pig.cpp', function 'pig_brain()':

if (!playing(spr[h].last_sound)) spr[h].last_sound = 0;

if (spr[h].last_sound == 0)
{
  if (hold == 1) 
    spr[h].last_sound = SoundPlayEffect( 2,junk, 800 ,h,0);
  if (hold == 2) 
    spr[h].last_sound = SoundPlayEffect( 3,junk, 800,h ,0);
  if (hold == 3) 
    spr[h].last_sound = SoundPlayEffect( 4,junk, 800 ,h,0);
  if (hold == 4) 
    spr[h].last_sound = SoundPlayEffect( 5,junk, 800,h,0 );


This clearly indicates that 'spr[h].last_sound' is supposed to hold a soundbank and not the channel, since 0 indicates the absence of a sound.

In conclusion, I agree with yeoldetoast's initial assessment, that not incrementing the value in 'playsound()' fixes the problem without any adverse side effects.

The second major change involves version checking. I was a bit surprised through how many hoops robj had to jump in order to identify the dink version. Therefore, I am proposing two new DinkC functions that shall make version identification a lot easier in the future:

- get_version_minor()
- get_fork()

Suppose you have freedink version 109.6. Your only chance to "identify" it is to call 'get_version()'. This, however, will return 108.
In the future, a call to get_version() shall return the correct major version number, e.g., the latest (development) version in my repository is 110.1. A call to 'get_version()' will return 110. An additional call to 'get_version_minor()' will return 1.

As I read in robj's earlier post, he indentifies dinkhd by the major version number, i.e., if the value from 'get_version()' is greater or equal than 110 then it is dinkhd. If freedink advances to major version 110 and beyond this would cause problems. This is where the fork number comes into play. By calling 'get_fork()' the exact fork/platform version would be identified, e.g., freedink will return 100.

Here is an excerpt of the corresponding commit message.

The following numbering convention for forks is proposed:

- fork numbers from 1 to 99 are reserved forks/sequels by the original
  creator(s), i.e., RTSoft, Seth Robinson
- fork numbers from 100 and higher can be chosen for forks by a
  3rd party, starting with 100 for freedink.



That is, *IF* Seth agrees that those additions are worthwhile. But even if not, at least the freedink versions should be easier to identify in the future.

PS:

I also find that setting SDL_FORCE_SOUNDFONTS and SDL_SOUNDFONTS to something results in a segfault when any MIDI is attempted to be played back!


I have never experienced this when setting those variables in Bash. I am using SDL2 2.0.9 and SDL2_mixer 2.0.4. Which are your version?