[smilymzx]

zzo38, on May 29 2009, 03:38 AM, said:

* New SMZX mode 141 for blinking text (like in ZZT)

Instead of the SMZX Blink Text concept, you can try to make every single thing blink by creating a new mode by enabling the use of SDL's DOS Blink Bit.

But you also must mod the main ''PlayerColor'' stuff to where the player has no colors under the player while testing/playing using the black background so he will not blink!

This post has been edited by smilymzx: 31 May 2009 - 04:29 PM

[zzo38]

smilymzx, on May 31 2009, 09:26 AM, said:

Instead of the SMZX Blink Text concept, you can try to make every single thing blink by creating a new mode by enabling the use of SDL's DOS Blink Bit.

I don't understand what SDL's DOS Blink Bit is. How I implemented it, mode 141 is exactly the same as mode 0 except that you cannot have background colors 8 to 15, if you choose those background colors then it will set it to 0 to 7 background color but makes the foreground color blink.

Quote

But you also must mod the main ''PlayerColor'' stuff to where the player has no colors under the player while testing/playing using the black background so he will not blink!

The default player color is c1b (or c1f for ZZT). And the player won't blink anyways if the screen uses a black background (unless you set the player color to c8b or c8f or something else that blinks).

I have made some progress on the Forth codes implementation. But I have a question, how to modify the thing_names table 128 to 254? And, can I make it load the names from thing_names for the thing menus 1,2,3,4,5,6,7,8 keys? (Currently, it just uses the names __ext_80, __ext_81, etc (numbers are in hex))

O, and I implemented a new A_ flag, A_INVISIBLE which causes it to use the color of what is underneath, and uses a black background if this is on the under layer. Extended kinds can set the A_INVISIBLE flag, and there is also a method of making it use the same char as the underneath also, by setting the CHAR ID value to 0 and then setting the extended kinds special CHAR ID list to tell it to copy the underneath char.

And the F4 menu is fixed now it shows the icon for the lock on that menu correctly.

This post has been edited by zzo38: 01 June 2009 - 03:07 AM

[smilymzx]

zzo38, on Jun 1 2009, 04:06 AM, said:

I don't understand what SDL's DOS Blink Bit is. How I implemented it, mode 141 is exactly the same as mode 0 except that you cannot have background colors 8 to 15, if you choose those background colors then it will set it to 0 to 7 background color but makes the foreground color blink.

Look at MZX's source code in Graphics.C (or .Cpp). That is where it is found. But if you already found a way, good for you.

zzo38, on Jun 1 2009, 04:06 AM, said:

The default player color is c1b (or c1f for ZZT). And the player won't blink anyways if the screen uses a black background (unless you set the player color to c8b or c8f or something else that blinks).

I mean when you use 'c0?' where '?' is the selected foreground color and the '0' (Transparency Enable) is the BG color

If you use any floor/space/passage while testing, playing, or editing when in blinking mode, Then the player will blink! If you can, modify the player code if it is 'c0?' it will either have no transparent effect, or use 8 background colors instead of 16 for transparency

[zzo38]

I fixed a bug where thick-webs acted like thin-webs. Now it works properly.

The code was:

	int web_flags = (move_flags & (MUST_WEB | MUST_THICKWEB)) >> 5;
	int web = (d_id == WEB) || (d_id == THICK_WEB);
	if((web < 1) || (web > 2))
	  web = 0;

	if(web_flags)
	{
	  // Must be one of these
	  if(!(web_flags & web))
		return HIT;
	}

But that makes no sense, "web" can only be 0 or 1 (because it is boolean), not 2 or 3 or anything else. The line if((web < 1) || (web > 2)) makes no sense anyways because if it was properly, it still could only be 0 or 1 or 2, so that line wouldn't change anything. I don't know who wrote that code, but obviously it is supposed to be "int web=(d_id == WEB)+(d_id == THICK_WEB)*2;" so I changed it to that (and removed the bogus condition). And I tested it, and now it works OK.

Well, actually that isn't exactly what I changed it to. Instead, I made 3 bits flag A_ELEMENT and used the element type 0 to 7 to check that. I also made it use that to check for water, fire, lava, goop. The element-type can be checked "int element_type=(d_flag&(A_ELEMENT*7))>>19;". Now you can make up extended kinds that can be moved over as those types of elements.

The element types are:

• NOTHING
  
• WATER
  
• FIRE
  
• LAVA
  
• GOOP
  
• THINWEB
  
• THICKWEB
  
• PLAYER

[ajs]

The original conversion from asm in 2.80 looked OK:

int web_flags = (move_flags & (MOVE_MUST_WEB | MOVE_MUST_THICKWEB)) >> 5;
int web = d_id - 17;
if((web < 1) || (web > 2)) web = 0;

if(web_flags)
{
   // Must be one of these
   if(!(web_flags & web))
	 return 1;
}

But it was broken in 2.81b. If you're interested in more history there's a git repository that compiles all of the source releases (so far up to 2.81f) of MZX available here: http://git.devzero.co.uk/. I hope to find the time to finish this project off, but it was done pretty thoroughly for all versions up to 2.81c. Each revision was downloaded off DMZX, junk removed from the zip, diffs minimised (unnecessary renames etc.) and then built with Borland C in DOSBOX. I also replaced the PRJ files with Makefiles that work without hacking and don't include machine-local paths.

--ajs.

[Exophase]

Casualty of the migration to the symbolic names.

If you're going to fix a bug could you do so without adding new things at the same time?

[ajs]

Or at least put them on the bug tracker so they aren't forgotten about. I've already added two minor things noted on this thread, but I don't know if that's comprehensive.

--ajs.

[zzo38]

Exophase, on Jun 3 2009, 01:52 PM, said:

Casualty of the migration to the symbolic names.

If you're going to fix a bug could you do so without adding new things at the same time?

Here it is:

	int web_flags = (move_flags & (MUST_WEB | MUST_THICKWEB)) >> 5;
	int web = (d_id == WEB)+(d_id == THICK_WEB)*2;
	if(web_flags)
	{
	  // Must be one of these
	  if(!(web_flags & web))
		return HIT;
	}

Also, I got the Forth codes to work! Here's an example of a code that works perfectly, it implements a ZZT key:

INCLUDE megazeux.4th
$82 12 A_ITEM A_PUSHABLE + 0 EXTKIND ZztKey
ZztKey EV.ITEM + :EVENT
  DROP BOARD_COLOR + @ DUP TAKEKEY SWAP GIVEKEY DROP
  IF
	"You already have the key!" SETMESG 9 BISFX 0
  ELSE
	"You now have the key." SETMESG 8 BISFX 1
  THEN
;

Just to help to understand, here is the stack effect for the EV.ITEM event: ( offset dir -- remove )

Note: This isn't actually exactly like a ZZT key. It doesn't convert dark colors to light colors (but that is easy to do by adding 8 OR after @), doesn't reproduce the black keys bug (but that's pretty unimportant for now), and it doesn't tell you what color it is on the message line (which can easily be fixed, but it takes a few more codes).

This post has been edited by zzo38: 05 June 2009 - 06:34 AM

[Exophase]

Thanks.

If ajs wants to implement, I'd rather go with this:

	int web_flags = (move_flags & (MUST_WEB | MUST_THICKWEB)) >> 5;
	int web_type = 0;

	if(d_id == WEB)
	  web_type = 1;
	else

	if(d_id == THICK_WEB)
	  web_type = 2;

	if(web_flags)
	{
	  // Must be one of these
	  if(!(web_flags & web_type))
		return HIT;
	}

Much less cryptic IMO.

[Lachesis]

Why would you want ZZT keys?

[zzo38]

Quote

Why would you want ZZT keys?

It can be used to make more accurate conversions of ZZT games into MegaZeux, but there are other reasons too, in case you want that or any other kind of items other than ZZT keys you can use the similar features. To clarify, ZZT keys are *not* built-in to PZX, instead you have to package a file of Forth codes with your game.

I have made a ZZT keys puzzle in the MZX game I made called Super ASCII MZX Town, but with the method I used, it requires robots to change CHAR ID values and you cannot use any of the following on the same board:

• Changing/removing robots
  
• Freeze-time
  
• Slow-time
  
• Explosives of any kind
  
• Allowing the player to use bombs
  
• Fire
  
• Wind
  
• Normal MZX keys of the same colors as the ZZT keys

(This method doesn't use any glitch of MegaZeux or any feature that is likely to be changed in the future.) If I make ZZT key puzzle in the sequel to that game, it will use PZX features and will use Forth codes instead, which will not mess up in these situations.

I have also implemented displacement overlay modes now, and also a 16 colors per character mode (now cutting the vertical resolution too), and a "cursor_mode" and "cursor_position" counter.

[Lachesis]

If you *really* need to do zzt keys, you should just do

. "example: purple key and door"
-----
. "@purplekey"
end
:touch
if "purplekey" = 1 "no"
set "purplekey" 1
* you got the purple key lulz
die item
:no
* you already have this junk gtfo btw this is why zzt keys suck
end
-----
. "@purpledoor"
end
:touch
if "purplekey" = 0 "no"
set "purplekey" 0
* you opened the purple door
die item
:no
* you need a purple key dumbass
end

Or, if you're HARDKORR

."@purple"
. "char 10 = door"
. "char 12 = key"
end
:touch
if "has&robotname&key" = "('this_char' = 12)" "no"
. "fuck the messages"
set "has&robotname&key" "(1-'has&robotname&key')"
sfx "whogivesashit"
die as item
: "no"
sfx "whousesthiscommandanyway"
end

This post has been edited by Kokuchou: 06 June 2009 - 03:28 AM

[zzo38]

Kokuchou, on Jun 5 2009, 07:15 PM, said:

If you *really* need to do zzt keys, you should just do

. "example: purple key and door"
-----
. "@purplekey"
end
:touch
if "purplekey" = 1 "no"
set "purplekey" 1
* you got the purple key lulz
die item
:no
* you already have this junk gtfo btw this is why zzt keys suck
end
-----
. "@purpledoor"
end
:touch
if "purplekey" = 0 "no"
set "purplekey" 0
* you opened the purple door
die item
:no
* you need a purple key dumbass
end

That won't work, for various reasons (well, it will work in some circumstances). For one, it can't be pushed. And if you make it a pushable robot then the player will be able to push it too. (It also uses a lot of robots and makes it much harder to PUT or CHANGE into keys/doors) And the bombs method happens to work in the circumstances I used them in the Super ASCII MZX Town game (ZZT keys are used only in one level there, and it uses normal MegaZeux locks), but the Forth codes for ZZT keys will work in all circumstances (and will work with normal MegaZeux locks, too). However, when converting a ZZT game into MegaZeux, this ZztKey definition will have to be modified a bit, and Forth codes for ZztDoor will also have to be written (the difference is the ZZT door uses the background color instead of the foreground color, and it also tells you which color it is).

For CoZZT, some things in ZZT can be converted to things already existing in MegaZeux:

• Normal -> Normal
  
• Solid -> Solid
  
• Breakable -> Breakaway
  
• Water -> Goop
  
• Object -> Robot
  
• Ammo -> Ammo

and so on. However, a lot of them cannot be converted.

And when converting ZZT-OOP codes to Robotic codes, you have to be aware of the differences, you also have to add some headings to each code converted (such as cycle 3, use enemy bullets, and various other things).

However, the Forth codes and other features I added are not only for CoZZT, they have many other uses as well.

[zzo38]

This code is a example breakout game (very simple) so you can see how some of the features works:

\ Breakout game in MegaZeux

INCLUDE megazeux.4th

$80 32 A_UPDATE 0 EXTKIND BreakoutControl
$81 3 0 0 EXTKIND HorWall
$82 3 0 0 EXTKIND VerWall
$83 4 0 0 EXTKIND Brick

: MOUSEPX "MOUSEPX" COUNTER@ ;
: ABS DUP 0 < IF -1 * THEN ;

2 DISPLACE_CHAR + CONSTANT BALLX
3 DISPLACE_CHAR + CONSTANT BALLY
4 DISPLACE_CHAR + CONSTANT PALLETX
5 DISPLACE_CHAR + CONSTANT PALLETY

1 VARIABLE BALLDX
-1 VARIABLE BALLDY

: BALLOFFSET BALLX @ 8 / BALLY @ 14 / 80 * + ;
: UPDATEPALLET MOUSEPX PALLETX ! 300 PALLETY ! ;
: MOVEBALL BALLX @ BALLDX @ + BALLX ! BALLY @ BALLDY @ + BALLY ! ;
: PALLETCOLLIDE BALLY @ PALLETY @ - ABS 8 < BALLX @ PALLETX @ - ABS 4 < AND ;
: WALLCOLLIDE BALLOFFSET BOARD_ID + @ = ;
: DESTROYBRICK Space BALLOFFSET BOARD_ID + ! ;

EV.LOADED :EVENT
  DROP
  \ Here we need to initialize the screen
  $AD "OVERLAY_MODE" COUNTER!
  4 DISPLACE_CHAR ! 4 DISPLACE_CHAR 1+ !
  0 DISPLACE_BG ! 2 DISPLACE_FG !
  \ Set ball attributes
  $01 2 DISPLACE_BG + !
  $C8 2 DISPLACE_FG + !
  $0 3 DISPLACE_BG + !
  $B 3 DISPLACE_FG + !
  \ Set pallet attributes
  $02 4 DISPLACE_BG + !
  $C8 4 DISPLACE_FG + !
  $0 5 DISPLACE_BG + !
  $A 5 DISPLACE_FG + !
  \ Let's start the ball in the center of the screen (approximately)
  320 BALLX ! 175 BALLY !
;

EV.UPDATE BreakoutControl + :EVENT
  DROP
  UPDATEPALLET
  MOVEBALL
  PALLETCOLLIDE IF 0 BISFX -1 BALLDY ! THEN
  HorWall WALLCOLLIDE IF 1 BISFX BALLDY @ -1 * BALLDY ! THEN
  VerWall WALLCOLLIDE IF 1 BISFX BALLDX @ -1 * BALLDX ! THEN
  Brick WALLCOLLIDE IF 2 BISFX DESTROYBRICK 1 BALLDY ! THEN
;

[zzo38]

You can now download it http://zzo38computer...1/mzx_extended/

[Sai'ke]

So how does this breakout code work then? I tried pasting it in a robot and it just gave me a list of syntax errors.

[zzo38]

Sai'ke, on Jun 13 2009, 12:54 PM, said:

So how does this breakout code work then? I tried pasting it in a robot and it just gave me a list of syntax errors.

You can't just paste it into a robot, because it isn't a Robotic code. Put it in a separate file and then you need to tell it to associate those Forth codes with the world. To associate Forth codes with a world, you make the first line of the global robot into a comment with a greater than sign followed by the name of the file containing the Forth codes (if you have a greater than sign without a filename, it will indicate a world that uses PZX features but with no Forth codes). Also make sure that any files of Forth codes that are included by that file are also in the same directory (almost always megazeux.4th but other files may be included as well, for example if you want to split your codes into multiple files).

This particular code for the breakout game is very simple and doesn't work at all like a real breakout game (it is meant only as an example to explain how it works). It expects a board with 80 columns, and you should edit the custom SFX (0 when the ball collides with the pallet, 1 when the ball collides with a wall, and 2 when the ball collides with a brick and breaks the brick), also edit the characters (it uses char 1 for the ball, char 2 for pallet, char 3 for walls, char 4 for bricks, but you can edit the Forth codes if you want to make it differently), and then place one BreakoutControl on the board and then place the HorWall and VerWall and Brick objects (push the number 1 key in the editor to place these objects, currently it will display the names _ext_80 to _ext_83 instead of the real names, but it will still work, and in version P2 it will be fixed to use the proper names of extended kinds).

Also note that there are still some things I will implement in version P2 (the current version is P1), such as a Forth command to add a board, and repointing the thing_names array properly when extended kinds are created, and treating CW IDLE special. And if you have other suggestions, I might implement those as well. I'm sorry that there isn't much documentation about these new features. Also please note that even if Forth codes are used, you can still use Robotic codes as well (including the global robot codes), and there are actually some improvements to the Robotic codes.

I will list some of the new things that can be used in Robotic codes:

• SEND "*" "word" calls a Forth code from a Robotic code.
  
• { and } operators in expressions are max/min operators.
  
• , operator evaluates the left side and sets that as the current parameter, and then the right side is evaluated and becomes the result of the expression. p can be used where a number can be used in an expression, and represents the current parameter value.
  
• `$stringname` in a expression evaluates an expression in a string, converting square brackets to parentheses before evaluation.
  
• `*forthword` calls a Forth code from an expression. The current parameter value will be pushed to the stack before execution of Forth word, when it exits then it will pop a number to use as the result of this expression.
  
• Other bits of the LAVA_WALK counter now mean something.
  
• "&^countername&" is replaced with the character using the number stored in that counter (for example if the counter value is 65 then it will be the letter "A").

This post has been edited by zzo38: 13 June 2009 - 08:28 PM

[Sai'ke]

Uh... I think it would be wise to include an example in the zip. Without one the chances of anyone using any of this are very slim.

[smilymzx]

I tried that ''comment-with-greater-sign'' method and it could not work!

Plus, Is The Blinking mode (set ''SMZX_MODE'' to 141) disabled for now, or is it not going to be there?

[zzo38]

smilymzx, on Jun 13 2009, 08:02 PM, said:

I tried that ''comment-with-greater-sign'' method and it could not work!

Plus, Is The Blinking mode (set ''SMZX_MODE'' to 141) disabled for now, or is it not going to be there?

Actually it works. Are you sure you have done it correctly? You need the first line of the global robot to be a comment with a greater-than sign as the first character (a filename is not required, but if you do put a filename, make sure the file exists and contains valid Forth codes). Make sure it is the first line (no blank lines or anything else before it), and it is the global robot (it won't do anything in another robot) (other Robotic codes in the global robot can still be used, but the first line must be the comment with greater-than-sign). If you do that, setting "SMZX_MODE" to 141 should work, and make it blink. Does the titlebar have "P1" at the end of the version number? If it doesn't, you have done something wrong in the installation. And, when trying to make it blink, do you have anything with background colors c8? to cf?? If you don't, that's why it won't blink. For example, put a light-gray on dark-gray (c87) text on the board and put a robot to set the SMZX_MODE to 141 and it will blink.

. ">"

This post has been edited by zzo38: 14 June 2009 - 04:15 AM

[Sai'ke]

Can't get it to work. There's nothing that tells me that it actually manages to load the forth stuff. Also, I can place the weird objects you added, but they don't have a character and are pretty much invisible. Could you upload a minimal example mzx file with associated forth codes?

[zzo38]

I have added a example world with Forth codes. (Also I have found some bugs, which will be corrected in version P2)

[smilymzx]

Now the blinking stuff works, But when using color c00-c0F as the playercolor while standing on something colored with blinking attributes, The player foreground Blinks. So I'd Request something for the next release like an SuperZZT-style 8-color transparency/background limit for everything when the player, puzzle objects and items is on the following items:

* Space
* Floor
* Carpet
* CustomFloor
* Fake
* Tiles
* Web and Thick Web
* Forest
* Stairs
* Cave
* Whirlpool
* Water and Water N,S,E and W
* Lava
* Ice
* Fire
* Sensor
* (Opened) Gate

And that is all,

NOTE: The blinking is a little too slow to match ZZT games.

This post has been edited by smilymzx: 14 June 2009 - 04:40 PM

[zzo38]

The blinking text in ZZT is done by the video card, not by ZZT itself. But I can make it a bit faster in the next release.

Forest is not A_UNDER, you probably mean forest to floor (actually Sensor is not A_UNDER either, it is A_SPEC_STOOD which means only the player can stand there). And I might implement the 8-color transparency/background limit on the under layer for when SMZX_MODE is 141 (a list of objects is not necessary, it is just the under layer, so anything on the under layer will be affected).

Thank you for your feedback about these changes to MegaZeux.

[smilymzx]

zzo38, on Jun 14 2009, 05:19 PM, said:

The blinking text in ZZT is done by the video card, not by ZZT itself. But I can make it a bit faster in the next release.

Forest is not A_UNDER, you probably mean forest to floor (actually Sensor is not A_UNDER either, it is A_SPEC_STOOD which means only the player can stand there). And I might implement the 8-color transparency/background limit on the under layer for when SMZX_MODE is 141 (a list of objects is not necessary, it is just the under layer, so anything on the under layer will be affected).

Thank you for your feedback about these changes to MegaZeux.

Heh, I should have not put in those two in the first place, so thanks for mentioning that!

BTW: Please change the window title and executable name to ProngZeux next release to avoid confusion, and edit the help file to match the changes you made.

This post has been edited by smilymzx: 15 June 2009 - 04:37 PM

[Koji]

this is blargh D:

[smilymzx]

Koji, on Jun 15 2009, 07:17 PM, said:

this is blargh D:

The reason I called it Prongzeux is that it is the name that the PZX abbreviation stands for.

Plus ZZO called it that name earlier in this thread

[iamgreaser]

Linker issue on FreeBSD:

[ben@roflcopter ~/Desktop/pzx]$ gmake
  MKDIR	src/.build
  CC	   src/board.c
  CC	   src/configure.c
  CC	   src/counter.c
  CC	   src/data.c
  CC	   src/decrypt.c
  CC	   src/error.c
  CC	   src/event.c
  CC	   src/expr.c
  CC	   src/forth.c
  CC	   src/fsafeopen.c
  CC	   src/game2.c
  CC	   src/game.c
src/game.c: In function 'play_game':
src/game.c:1768: warning: comparison between signed and unsigned
  CC	   src/graphics.c
  CC	   src/idarray.c
  CC	   src/idput.c
src/idput.c: In function 'get_id_color':
src/idput.c:466: warning: array subscript has type 'char'
  CC	   src/intake.c
  CC	   src/mzm.c
  CC	   src/rasm.c
  CC	   src/render.c
  CC	   src/robot.c
  CC	   src/runrobo2.c
  CC	   src/scrdisp.c
  CC	   src/sfx.c
  CC	   src/sprite.c
  CC	   src/util.c
  CC	   src/window.c
  CC	   src/world.c
  CC	   src/debug.c
  CC	   src/helpsys.c
  CC	   src/render_soft.c
  CC	   src/render_gl.c
In file included from /usr/local/include/SDL/SDL_opengl.h:45,
				 from src/render_gl.h:29,
				 from src/render_gl.c:25:
/usr/local/include/GL/glu.h:287: warning: function declaration isn't a prototype
  CC	   src/render_gl1.c
In file included from /usr/local/include/SDL/SDL_opengl.h:45,
				 from src/render_gl.h:29,
				 from src/render_gl1.c:29:
/usr/local/include/GL/glu.h:287: warning: function declaration isn't a prototype
  CC	   src/render_gl2.c
In file included from /usr/local/include/SDL/SDL_opengl.h:45,
				 from src/render_gl.h:29,
				 from src/render_gl2.c:29:
/usr/local/include/GL/glu.h:287: warning: function declaration isn't a prototype
  CC	   src/render_glsl.c
In file included from /usr/local/include/SDL/SDL_opengl.h:45,
				 from src/render_gl.h:29,
				 from src/render_glsl.c:28:
/usr/local/include/GL/glu.h:287: warning: function declaration isn't a prototype
  CC	   src/render_yuv.c
  CC	   src/render_yuv1.c
  CC	   src/render_yuv2.c
  MKDIR	contrib/gdm2s3m/src/.build
  CC	   contrib/gdm2s3m/src/error.c
  CC	   contrib/gdm2s3m/src/gdm.c
  CC	   contrib/gdm2s3m/src/s3m.c
  CC	   contrib/gdm2s3m/src/utility.c
  CC	   contrib/gdm2s3m/src/gdm2s3m.c
  CC	   src/pngops.c
  CC	   src/audio.c
/usr/local/include/vorbis/vorbisfile.h:56: warning: 'OV_CALLBACKS_DEFAULT' defined but not used
/usr/local/include/vorbis/vorbisfile.h:63: warning: 'OV_CALLBACKS_NOCLOSE' defined but not used
/usr/local/include/vorbis/vorbisfile.h:70: warning: 'OV_CALLBACKS_STREAMONLY' defined but not used
/usr/local/include/vorbis/vorbisfile.h:77: warning: 'OV_CALLBACKS_STREAMONLY_NOCLOSE' defined but not used
  CC	   src/event_sdl.c
  CC	   src/platform_sdl.c
  CC	   src/render_sdl.c
  CC	   src/audio_sdl.c
  CXX	  src/audio_modplug.cpp
  MKDIR	contrib/libmodplug/src/.build
  CXX	  contrib/libmodplug/src/fastmix.cpp
  CXX	  contrib/libmodplug/src/load_669.cpp
  CXX	  contrib/libmodplug/src/load_amf.cpp
  CXX	  contrib/libmodplug/src/load_dsm.cpp
  CXX	  contrib/libmodplug/src/load_far.cpp
  CXX	  contrib/libmodplug/src/load_it.cpp
  CXX	  contrib/libmodplug/src/load_med.cpp
  CXX	  contrib/libmodplug/src/load_mod.cpp
  CXX	  contrib/libmodplug/src/load_mtm.cpp
  CXX	  contrib/libmodplug/src/load_okt.cpp
  CXX	  contrib/libmodplug/src/load_s3m.cpp
  CXX	  contrib/libmodplug/src/load_stm.cpp
  CXX	  contrib/libmodplug/src/load_ult.cpp
  CXX	  contrib/libmodplug/src/load_wav.cpp
  CXX	  contrib/libmodplug/src/load_xm.cpp
  CXX	  contrib/libmodplug/src/mmcmp.cpp
  CXX	  contrib/libmodplug/src/modplug.cpp
  CXX	  contrib/libmodplug/src/snd_dsp.cpp
  CXX	  contrib/libmodplug/src/sndfile.cpp
  CXX	  contrib/libmodplug/src/snd_flt.cpp
  CXX	  contrib/libmodplug/src/snd_fx.cpp
  CXX	  contrib/libmodplug/src/sndmix.cpp
  CXX	  contrib/libmodplug/src/tables.cpp
  LINK	 libcore.so
  CC	   src/main.c
  CC	   src/run_stubs.c
  LINK	 mzxrun
/usr/bin/ld: mzxrun: hidden symbol `change_board_size' in src/.build/run_stubs.o is referenced by DSO
gmake: *** [mzxrun] Error 1
[ben@roflcopter ~/Desktop/pzx]$

How the hell do you get a hidden symbol in C anyway?!?!
I've had a look and a hack but the reason for this atrosity still escapes me.

I'm hacking out mzxrun from the Makefile for now. And we continue...

[ben@roflcopter ~/Desktop/pzx]$ gmake
  MKDIR	src/editor/.build
  CC	   src/editor/board.c
  CC	   src/editor/block.c
  CC	   src/editor/configure.c
  CC	   src/editor/char_ed.c
  CC	   src/editor/edit.c
  CC	   src/editor/edit_di.c
  CC	   src/editor/fill.c
  CC	   src/editor/graphics.c
  CC	   src/editor/macro.c
  CC	   src/editor/pal_ed.c
  CC	   src/editor/param.c
  CC	   src/editor/robo_ed.c
  CC	   src/editor/robot.c
  CC	   src/editor/sfx_edit.c
  CC	   src/editor/window.c
  CC	   src/editor/world.c
  LINK	 libeditor.so
  MKDIR	src/network/.build
  CC	   src/network/host.c
  CC	   src/network/manifest.c
  CC	   src/network/sha256.c
  LINK	 libnetwork.so
  CC	   src/updater.c
  LINK	 megazeux
./libcore.so: undefined reference to `change_board_size'
./libeditor.so: undefined reference to `forth_dpush'
./libeditor.so: undefined reference to `forth_run'
./libeditor.so: undefined reference to `check_pzx_version'
./libeditor.so: undefined reference to `forth_dpop'

OK, disabling modular build as this seems to be just a little bit COMPLETELY STUPID... Ah!

...
  CC	   src/main.c
  CC	   src/updater.c
  LINK	 megazeux
  MKDIR	src/utils/.build
  CC	   src/utils/checkres.c
  MKDIR	contrib/unzip/src/.build
  CC	   contrib/unzip/src/unzip.c
  CC	   contrib/unzip/src/ioapi.c
  LINK	 src/utils/checkres
  CC	   src/utils/downver.c
  LINK	 src/utils/downver
  CC	   src/utils/hlp2txt.c
  LINK	 src/utils/hlp2txt
  CC	   src/utils/txt2hlp.c
  LINK	 src/utils/txt2hlp
[ben@roflcopter ~/Desktop/pzx]$

OK, seeing as you've pretty much broken the code in terms of modularity, you might as well break it some more and do some work on the editor.

Also, I tried the example. The bomb switch thing works. But I don't have any bombs. Suggestion: if you're going to improve on the example, at least give the player some bombs.

[zzo38]

Quote

./libcore.so: undefined reference to `change_board_size'
./libeditor.so: undefined reference to `forth_dpush'
./libeditor.so: undefined reference to `forth_run'
./libeditor.so: undefined reference to `check_pzx_version'
./libeditor.so: undefined reference to `forth_dpop'

The problem is probably forgetting CORE_LIBSPEC. I will add EDITOR_LIBSPEC to "change_board_size" and CORE_LIBSPEC for the other four functions, and see if this fixes the problem.

Quote

hidden symbol `change_board_size' in src/.build/run_stubs.o is referenced by DSO

What does this mean anyways? I could try making "change_board_size" EDITOR_LIBSPEC to see if that fixes it.

And I have never gotten these warnings on my computer (except for the game.c and idput.c warnings). (But I have not compiled it modular anyways)

Quote

Also, I tried the example. The bomb switch thing works. But I don't have any bombs. Suggestion: if you're going to improve on the example, at least give the player some bombs.

I can fix this with the release of version P2 (I already added some features and fixed many bugs in it, and may release it soon).

I also have a complete list of PZX attribute flags and events at http://www.digitalmzx.com/wiki/PZX in addition to an example Forth code with explanation. Please tell me if you can understand it or not, and if you think it is good explanations or not.

[ajs]

Just to explain what's going on here..

When I moved MZX to modular recently, Windows caused problems, because for DLLs to work there you have to have an explicit symbol map pre-determined at link-time. Symbols are not visible by default. Rather than play games with dlltool, I opted to annotate all functions that needed to be exported from core.dll (CORE_LIBSPEC) and editor.dll (EDITOR_LIBSPEC). On Windows this expands to dllspec_export or something like that. On Linux, I used a feature added in GCC 3.x to set the default visibility of symbols to hidden, then I can use __attribute__((visible)) to show them again. This way the shared objects load faster with no unnecessary relocations.

If GCC is warning about these problems, there are simply bugs in PZX.

@iamgreaser: FWIW symbols in ELF or COFF DSOs have nothing whatsoever to do with the language. The C specification doesn't even mention DSOs. Also, MZX isn't just C, it also uses C++ code (modplug) and is typically linked with g++.

--ajs.