R'n'D 2019.01.07 build review

Discussion about Rocks'n'Diamonds, Boulder Dash, Supaplex, Emerald Mine and any other BD hybrid.

Moderators: Zomis, Flumminator

Post Reply
User avatar
Eizzoux
Posts: 271
Joined: Wed Oct 30, 2013 5:32 am
Location: Russia
Contact:

R'n'D 2019.01.07 build review

Post by Eizzoux » Sun Jan 20, 2019 7:29 am

Yeah, it came out two weeks ago, but whatever...
Checked that "new" dev version from January 7th, checked if some things are fixed or if some things are added.
First I checked Setup menu > Game & Menu. The only new option is Ask on Game Over - If every player dies, the message "Game Over! Play it again?" and Y/N options pops out on panel. Nothing else new in Setup menu.
0.png
0.png (779.45 KiB) Viewed 284 times
Then I visited editor. Turned on the "Automatically count gems needed", put every type of gem: four Emeralds, BD Diamond, EM Diamond, Pearl, Crystal, Infotron - they all count. Even walls with gems and nut are counting.
1.png
1.png (120.66 KiB) Viewed 284 times
Then I checked if editor icon of Steel Char Space is fixed... Fortunately, no, it's still without blue tone.
2.png
2.png (16.56 KiB) Viewed 284 times
I remembered an idea of adding an option of ending the level by filling all sokoban fields in any non-sokoban level. I checked properties of sokoban objects and... yeah, two more options. One is for all three SB elements (empty and full SB field and SB object) - "Exit level if all tasks solved", and second only for empty SB field and SB object - "All fields need to be filled"/"All objects need to be placed".
3.png
3.png (24.52 KiB) Viewed 284 times
I put two players in a new level, and tried digging with first player around second, and I see that bug is really fixed (in older versions it would use wrong border nearby second player)
4.png
4.png (82 KiB) Viewed 284 times
I also found a little... bug... I don't know... when you have empty space in editor palette, try changing an emerald to wall with emerald by holding Shift and LMB on one element, then start moving cursor around on it, it will be changing. I'm guessing that happens because empty space is only element in R'n'D/MM which can exist as normal full tile AND as a quarter of tile, so game kind of counts your empty space tile as a quarter one, so when you move your cursor around in boundaries of one big tile, you're moving between four mini-tiles.
5.gif
5.gif (210.87 KiB) Viewed 284 times
What's even more interesting, on any engine, except MM, any mini block (MM/DF Steel walls, MM/DF Wooden walls, Amoeba wall, Ice wall) will fill in the entire tile manually in drawing on a single click.
6.gif
6.gif (181.16 KiB) Viewed 284 times
I checked if anything is changed in MM engine, but I guess, it was left unchanged since Holger is more focussed on R'n'D than MM. All bugs I found are all the same, still cutting corners of tiles, still invincibility with fuse, still too many teleportations cuts the beam eventually and etc.
Also I checked if first_level/last_level/level_number buttons are lightening up on click. And yes, they do.
7.png
7.png (34.31 KiB) Viewed 284 times
Well, I didn't find anything else, so I guess there's nothing else new, but maybe I missed something, I don't know.
Nothing in here...*

User avatar
Holger
Site Admin
Posts: 3070
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: R'n'D 2019.01.07 build review

Post by Holger » Sun Jan 20, 2019 4:39 pm

For a complete list of changes, just have a look at the Git log (normal log, not shortlog):

https://git.artsoft.org/?p=rocksndiamonds.git;a=log

(It's not up-to-date though... I should push the last changes, too, which, for example, added drag-and-drop support for level set packages in zip files, which will be automatically extracted and activated when dropped into the R'n'D window...)

And thanks a lot for showing some of the changes in your post (plus reporting some bugs)! :D

User avatar
Holger
Site Admin
Posts: 3070
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: R'n'D 2019.01.07 build review

Post by Holger » Tue Jan 29, 2019 11:26 pm

OK, I've pushed the latest code to the Git repo now. And for the Windows folks, I've uploaded an updated executable for testing here: https://www.artsoft.org/RELEASES/rocksn ... 0130-1.exe

The most interesting new feature is probably the new drag-and-drop support for level set packages in zip files, which will be automatically extracted and activated when dropped into the R'n'D window (tested with Windows 7 and Linux/KDE). If you drop the zip files into the "level set selection" menu, it will be added in the currently displayed folder. (If you drop the zip file while in the main menu, the new set will automatically be activated, while you have to select it manually when dropping it while in the "level set selection" menu.)

Alternatively, just copy the level set zip file into the levels folder or sub-folder (where you would have extracted it into before) and it will be automatically extracted there when starting the program.

This should hopefully be quite close to the upcoming new version 4.1.2.0, so you may want to give it a try to find last bugs of the "show stopper" category, if there should be any (which I do not hope).

filbo
Posts: 342
Joined: Fri Jun 20, 2014 10:06 am

Re: R'n'D 2019.01.07 build review

Post by filbo » Wed Jan 30, 2019 4:36 am

events.c: In function ‘HandleOtherEvents’:
events.c:271:10: error: ‘SDL_DROPBEGIN’ undeclared (first use in this function)

etc.

Quick googling indicates drag-n-drop was added in SDL 2.0.5, I'm currently on 2.0.2. Can probably upgrade, but, this will be a hassle for various individuals and possibly distros. SDL 2.0.5 announcement was 2016-10-20, I'm on LinuxMint 17.3 which is based on Ubuntu 14.04 (therefore most of its repository libraries date to 2014 or earlier).

Build and quick run-test work after patching it out:

Code: Select all

diff --git a/src/events.c b/src/events.c
index 0d1f6ba..e33a0fc 100644
--- a/src/events.c
+++ b/src/events.c
@@ -269,4 +269,6 @@ void HandleOtherEvents(Event *event)
       break;
 
+// SDL drag-and-drop support was added in 2.0.5
+#if defined(SDL_DROPBEGIN)
     case SDL_DROPBEGIN:
     case SDL_DROPCOMPLETE:
@@ -275,4 +277,5 @@ void HandleOtherEvents(Event *event)
       HandleDropEvent(event);
       break;
+#endif
 
     default:
@@ -1526,4 +1529,5 @@ void HandleClientMessageEvent(ClientMessageEvent *event)
 }
 
+#if defined(SDL_DROPBEGIN)
 static boolean HandleDropFileEvent(char *filename)
 {
@@ -1644,4 +1648,5 @@ void HandleDropEvent(Event *event)
     SDL_free(event->drop.file);
 }
+#endif
 
 void HandleButton(int mx, int my, int button, int button_nr)
BTW you might want to make a separate post about impending release, if you want people to look at it...

User avatar
Holger
Site Admin
Posts: 3070
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: R'n'D 2019.01.07 build review

Post by Holger » Sat Feb 02, 2019 10:39 am

Drag-and-drop support was indeed already supported by earlier SDL versions (supporting only SDL_DROPFILE then), but it was extended in version 2.0.5 (with especially SDL_DROPBEGIN and SDL_DROPCOMPLETE being very useful when dropping multiple files at once).

However, there's a little problem with your patch with "#if defined(SDL_DROPBEGIN)" being always FALSE regardless of what SDL version is installed; that's because SDL_DROPBEGIN is not a preprocessor macro, but an enum, so SDL_DROPBEGIN is only known at compile time, while therefore always being zero at preprocessing stage.

This patch should do it:

Code: Select all

diff --git a/src/events.c b/src/events.c
index 0d1f6ba..b3e4c81 100644
--- a/src/events.c
+++ b/src/events.c
@@ -268,12 +268,14 @@ void HandleOtherEvents(Event *event)
       HandleJoystickEvent(event);
       break;
 
+#if defined(USE_DRAG_AND_DROP)
     case SDL_DROPBEGIN:
     case SDL_DROPCOMPLETE:
     case SDL_DROPFILE:
     case SDL_DROPTEXT:
       HandleDropEvent(event);
       break;
+#endif
 
     default:
       break;
@@ -1525,6 +1527,7 @@ void HandleClientMessageEvent(ClientMessageEvent *event)
     CloseAllAndExit(0);
 }
 
+#if defined(USE_DRAG_AND_DROP)
 static boolean HandleDropFileEvent(char *filename)
 {
   Error(ERR_DEBUG, "DROP FILE EVENT: '%s'", filename);
@@ -1643,6 +1646,7 @@ void HandleDropEvent(Event *event)
   if (event->drop.file != NULL)
     SDL_free(event->drop.file);
 }
+#endif
 
 void HandleButton(int mx, int my, int button, int button_nr)
 {
diff --git a/src/libgame/system.h b/src/libgame/system.h
index bab4957..73fc371 100644
--- a/src/libgame/system.h
+++ b/src/libgame/system.h
@@ -118,6 +118,11 @@
 #define SCREEN_KEYBOARD_POS(h)         ((h) / 2)
 #endif
 
+// values for drag-and-drop support (some parts not added before SDL 2.0.5)
+#if SDL_VERSION_ATLEAST(2,0,5)
+#define USE_DRAG_AND_DROP
+#endif
+
 // default input keys
 #define DEFAULT_KEY_LEFT               KSYM_Left
 #define DEFAULT_KEY_RIGHT              KSYM_Right
Please "git pull" and retry! :-)
BTW you might want to make a separate post about impending release, if you want people to look at it...
Yeah, you're probably right... either that, or just throwing out 4.1.2.0 "as is" and quickly adding a patch release 4.1.2.1 afterwards, if needed (as some people can not build by themselves).

filbo
Posts: 342
Joined: Fri Jun 20, 2014 10:06 am

Re: R'n'D 2019.01.07 build review

Post by filbo » Sun Feb 03, 2019 1:39 am

Yes, compiles clean...

I'm amused that my #ifdef was no good because it was an enum not a preprocessor symbol. Too bad C doesn't have a '#if is_evaluatable()' or something like that...

User avatar
Holger
Site Admin
Posts: 3070
Joined: Fri Jun 18, 2004 4:13 pm
Location: Germany
Contact:

Re: R'n'D 2019.01.07 build review

Post by Holger » Sun Feb 03, 2019 9:11 am

I'm amused that my #ifdef was no good because it was an enum not a preprocessor symbol. Too bad C doesn't have a '#if is_evaluatable()' or something like that...
Yes, exactly. I was quite confused at first why your patch did not work, because I thought SDL_DROPBEGIN would be a preprocessor macro (#define), and then found out that it's an enum value.

Even though enums are really better (because they are known at compile time by their name), it really makes it harder to check if they are defined or not if used to "#define" style constants... :-/

Post Reply