First, thanks for DGEN/SDL, it works fine, and it feels good to play old SEGA games !
I'm also a big fan of a special kind of games, called "programming games", where the goal is to write an efficient program that will control a robot in the game, for example. If you never heard of it, here's a link about programming games : http://programminggames.org/
I like the concept, since i like coding, but most existing programming games are disappointing to me. So here is the idea (not a project yet ;) =
Do you think it would be possible for me to create a version of DGEN that would allow programs to play Megadrive games ?
As output, player-programs would simply use the joypad, nothing tricky.
Now, as input, it's a bit harder. Player-programs would need to know what sprites are currently on the screen, what is their type, their current state, and their position.
I think it would be fun, especially with two player games, but i don't even know whether it's technically feasible, since i don't know yet how DGEN works… (i just started digging, ten minutes ago)
So what do you think ?
Is it feasible ?
If it is, would you allow me to make a derived version of DGen, or an addon/upgrade/whatever ?
Would you help me a little bit, if i need help somewhere ?
Anyway, once again thanks for DGen !
Julien
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
First, nothing prevents you from forking and doing as you please with DGen/SDL (only integrating your changes back into mainline may not be feasible for various reasons afterwards).
Programming games are fun indeed (at least the only one I know about, core war), but I don't think I understand your idea.
Do you want to create a full MegaDrive game from scratch using DGen/SDL to run it, or code some kind of AI to play existing games? The former doesn't require any change to DGen/SDL (unless bugs need to be fixed), and require you to learn about how to program for MegaDrive (M68K, or C using Stef's toolchain), while the latter, depending on the game, may be quite tricky. Accessing sprites memory is easy, interpreting it not so much (i.e. some sprites are hidden, some overlap others with various weird rules/bugs and a lot more).
Now I warn you, DGen/SDL has, erm, "code quality issues" that I hope won't discourage you.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry to necro-thread but this was the question I had too and there is a solution in MSYS2. sscanf
The most direct method is to override the makefile variable while building pbm2df itself, then make the remainder as usual:
test -f autogen.sh && ./autogen.sh || autoreconf -vif
mkdir build && cd build
../configure --enable-debugger --enable-debug-vdp --enable-pico --enable-vgmdump --with-musa --with-mz80 --with-cz80 --with-dz80 --prefix=$PWD
make -C sdl CFLAGS_FOR_BUILD="-D__USE_MINGW_ANSI_STDIO=1" pbm2df.exe -j4
make CFLAGS="-static-libgcc" CXXFLAGS="-static-libgcc -static-libstdc++" CPPFLAGS="-I$MINGW_PREFIX/include/SDL" -j4 install-strip
Alternatively, a patch can be used:
diff --git a/configure.ac b/configure.acindex df34819..3a8c234 100644--- a/configure.ac+++ b/configure.ac@@ -13,7 +13,7 @@ dnl We'll need machine type later.AC_CANONICAL_SYSTEM
dnl Initialize Automake.
-AM_INIT_AUTOMAKE([silent-rules])+AM_INIT_AUTOMAKE([silent-rules subdir-objects])AM_SILENT_RULES([yes])
AM_PROG_AS
diff --git a/sdl/pbm2df.c b/sdl/pbm2df.cindex eb94390..b9dc3a9 100644--- a/sdl/pbm2df.c+++ b/sdl/pbm2df.c@@ -2,7 +2,10 @@ * PBM. The PBM width should be divisible by 96, with cells which from left to
* right are the glyphs from 0x20 (space) to 0x7f (character after ~).
* The color 1 in the PBM is opaque, and 0 is transparent. */
-++#if defined(__MINGW32__)+#define __USE_MINGW_ANSI_STDIO 1+#endif#include <stdio.h>
#include <stdlib.h>
#include <string.h>
configure.ac makes modern automake happy and the changes to pbm2df.c apply the mingw work-around.
Last edit: noa body 2019-09-08
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Sorry for the delay. You can PM me (as you already did) but please try to keep questions here on the forum so everyone can benefit from them and get a chance to reply. I'm replying to your email here as well.
The DGen/SDL builds provided in the downloads section are made using MinGW under Linux, that is, I cross-compile from Linux to Win32/64, so I don't know what to expect purely under Windows.
However, if you're this far, I guess as long as you have SDL headers somewhere and some sort of .dll elsewhere, you can try -with-sdl-prefix=/$something (./configure should append "/lib" and/or "/include" to this path, at least that's how it is under Linux). You may also override CPPFLAGS, LDFLAGS or even CC to point to these directories, for instance:
CC='gcc-whatever -I/$somewhere/include/ -L/$somewhere/lib' ./configure -foo && make
Hope this helps, keep me updated on your programming game conversion progress!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I had to get rid of the "bad magic" "goto error" in pbm2df. Don't know why.
Then i generated the dgen_font_##x##.cpp by myself, using pbm2df.
And then, i had to put the content of the 3 dgen_font_##x##.cpp directly inside font.cpp !
Finally, i copied every dll found in mingw/bin into the folder where my executable is.
Then i had a fight me-ChunLi vs cpu-Ryu, but i couldn't defeat his dragon-punch :)
Now i can start playing around…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm currently looking for a language… My first idea was to use a simple scripting language for AIs, then i realised that it wouldn't be fun if it's too easy (if-then, if-then, if-then, …). So perhaps it will be something more esoteric, like FALSE maybe ! Right now i'm trying to figure out how i'm gonna get sprites coords and types in a FALSE-like homebrew language.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Edsger Dijkstra
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.
I made a choice : AIs will be coded in good old unstructured BASIC (line-numbered) !!!
Homebrew featuring :
- floats, strings
- Judy arrays
- self-modifying ability
- player-programs can read opponent's code and current state
- interrupts (like EVERY and AFTER from Locomotive BASIC)
- compiled to bytecode, then executed
By the way, you were right about pbm2df. It works fine when you test both \n and \r\n…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
"It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration." Edsger Dijkstra
I made a choice : AIs will be coded in good old unstructured BASIC (line-numbered) !!!
Homebrew featuring :
- floats, strings
- Judy arrays http://judy.sourceforge.net/
- self-modifying ability
- player-programs can read opponent's code and current state
- interrupts (like EVERY and AFTER from Locomotive BASIC http://en.wikipedia.org/wiki/Locomotive_BASIC )
- compiled to bytecode, then executed
By the way, you were right about pbm2df. It works fine when you test both \n and \r\n…
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
FALSE, then BASIC? I'll agree with Dijkstra on that one!
Ok, about the pbm2df issue, I'll fix this eventually.
About -m, on Linux and BSD there's no such check because if you don't run DGen from a terminal, stdin will typically be redirected to /dev/null and the isatty() check in linenoise will assume a dumb terminal from which nothing will be read.
So in a sense the text console is always available. Remember it's currently only used by the debugger when enabled.
There's normally no "parent console" concept in Windows so I had to add a way to use the debugger without having to keep a console window opened when the debugger isn't necessary, hence the -m option.
No problem with printf(), however you will get mixed output (your own messages and DGen's in the same stream). This can be mitigated using dup() and fdopen() (which may not be implemented in MinGW) to create a separate stream.
gets() is a different story. During startup, DGen may read read its configuration file from stdin, then the debugger may also read it when enabled, so you should make sure to disable both first, otherwise you'll also need to open a separate stream using fopen(), since duplicating stdin like stdout won't solve the conflict.
Anyway, if you want interaction with a prompt, you should check how it's done in the debugger (with linenoise); you can probably reuse something in debug.cpp.
Hope this helps.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Finally, i think i'll make a separate shell : simple, portable… I'll try to make it feel like Amstrad CPC464. It will be used to launch the emulator and modify player-programs, even while the emulator is running. Then, user can press F7 or F8 to reload bot1 or bot2 code directly, without restarting the game.
I already have my "spriter" : when F4 is pressed, the game is paused and you can get the sprites' hashes that player-bots will use to "recognize" sprites. It works fine !
Just to be sure : how many bytes should i hash ? Right now i pick :
info.tw*info.th*4*(8 << info.inter) chars
…starting from (info.tile). Does it look ok to you ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi i'm Julien, from France.
First, thanks for DGEN/SDL, it works fine, and it feels good to play old SEGA games !
I'm also a big fan of a special kind of games, called "programming games", where the goal is to write an efficient program that will control a robot in the game, for example. If you never heard of it, here's a link about programming games :
http://programminggames.org/
I like the concept, since i like coding, but most existing programming games are disappointing to me. So here is the idea (not a project yet ;) =
Do you think it would be possible for me to create a version of DGEN that would allow programs to play Megadrive games ?
As output, player-programs would simply use the joypad, nothing tricky.
Now, as input, it's a bit harder. Player-programs would need to know what sprites are currently on the screen, what is their type, their current state, and their position.
I think it would be fun, especially with two player games, but i don't even know whether it's technically feasible, since i don't know yet how DGEN works… (i just started digging, ten minutes ago)
So what do you think ?
Is it feasible ?
If it is, would you allow me to make a derived version of DGen, or an addon/upgrade/whatever ?
Would you help me a little bit, if i need help somewhere ?
Anyway, once again thanks for DGen !
Julien
Hi Julien, thanks for your feedback.
First, nothing prevents you from forking and doing as you please with DGen/SDL (only integrating your changes back into mainline may not be feasible for various reasons afterwards).
Programming games are fun indeed (at least the only one I know about, core war), but I don't think I understand your idea.
Do you want to create a full MegaDrive game from scratch using DGen/SDL to run it, or code some kind of AI to play existing games? The former doesn't require any change to DGen/SDL (unless bugs need to be fixed), and require you to learn about how to program for MegaDrive (M68K, or C using Stef's toolchain), while the latter, depending on the game, may be quite tricky. Accessing sprites memory is easy, interpreting it not so much (i.e. some sprites are hidden, some overlap others with various weird rules/bugs and a lot more).
Now I warn you, DGen/SDL has, erm, "code quality issues" that I hope won't discourage you.
Ok :)
I don't want to create a full Megadrive game.
I don't want to code some kind of AI to play existing games.
I want to extend Dgen so USERS can easily code AIs to play existing games. In other words, i want to turn DGen into a programming game.
So i guess i'm gonna fork !
Can i PM you, if i have a few questions ?
Hi Zamaz,
I'm trying to build DGen/SDL with mingw / msys
I installed SDL, following this procedure :
http://www.netadelica.com/coding/sdl/install.html
I also tried to put "SDL-devel" in "dgen" folder.
AM_PATH_SDL is not found. So, "configure" doesn't work.
I keep googling and googling again, i swear. But here, i'm stuck.
Would you help a poor newbie please ?
Sorry to necro-thread but this was the question I had too and there is a solution in MSYS2. sscanf
The most direct method is to override the makefile variable while building pbm2df itself, then make the remainder as usual:
Alternatively, a patch can be used:
configure.ac makes modern automake happy and the changes to pbm2df.c apply the mingw work-around.
Last edit: noa body 2019-09-08
Hey Julien,
Sorry for the delay. You can PM me (as you already did) but please try to keep questions here on the forum so everyone can benefit from them and get a chance to reply. I'm replying to your email here as well.
The DGen/SDL builds provided in the downloads section are made using MinGW under Linux, that is, I cross-compile from Linux to Win32/64, so I don't know what to expect purely under Windows.
However, if you're this far, I guess as long as you have SDL headers somewhere and some sort of .dll elsewhere, you can try -with-sdl-prefix=/$something (./configure should append "/lib" and/or "/include" to this path, at least that's how it is under Linux). You may also override CPPFLAGS, LDFLAGS or even CC to point to these directories, for instance:
CC='gcc-whatever -I/$somewhere/include/ -L/$somewhere/lib' ./configure -foo && make
Hope this helps, keep me updated on your programming game conversion progress!
Thanks a lot, Zamaz :)
I'm almost there !
Almost… pbm2df doesn't want to convert from .pbm to .cpp
It says "bad magic". But i checked : .pbm files do begin with "P1\n".
Any idea ?
got it !!! waow
I had to get rid of the "bad magic" "goto error" in pbm2df. Don't know why.
Then i generated the dgen_font_##x##.cpp by myself, using pbm2df.
And then, i had to put the content of the 3 dgen_font_##x##.cpp directly inside font.cpp !
Finally, i copied every dll found in mingw/bin into the folder where my executable is.
Then i had a fight me-ChunLi vs cpu-Ryu, but i couldn't defeat his dragon-punch :)
Now i can start playing around…
Great!
About pbm2df, it may be caused by that nasty \n matched by sscanf(). Should probably be \r\n under Windows or something like that.
Hi ! just giving news…
I'm currently looking for a language… My first idea was to use a simple scripting language for AIs, then i realised that it wouldn't be fun if it's too easy (if-then, if-then, if-then, …). So perhaps it will be something more esoteric, like FALSE maybe ! Right now i'm trying to figure out how i'm gonna get sprites coords and types in a FALSE-like homebrew language.
I made a choice : AIs will be coded in good old unstructured BASIC (line-numbered) !!!
Homebrew featuring :
- floats, strings
- Judy arrays
- self-modifying ability
- player-programs can read opponent's code and current state
- interrupts (like EVERY and AFTER from Locomotive BASIC)
- compiled to bytecode, then executed
By the way, you were right about pbm2df. It works fine when you test both \n and \r\n…
I made a choice : AIs will be coded in good old unstructured BASIC (line-numbered) !!!
Homebrew featuring :
- floats, strings
- Judy arrays http://judy.sourceforge.net/
- self-modifying ability
- player-programs can read opponent's code and current state
- interrupts (like EVERY and AFTER from Locomotive BASIC http://en.wikipedia.org/wiki/Locomotive_BASIC )
- compiled to bytecode, then executed
By the way, you were right about pbm2df. It works fine when you test both \n and \r\n…
Hi,
I have a question. In DGen there is a -m option. This option prevents DGen from detaching from its control console. It's on MinGW only.
My question is : how does it behave on Linux ? Is the console always available ? or does it always disappear ?
I'd like to use the console to interact with the user, simply with printf() or gets() for example. Would it work on Linux ?
Hi!
FALSE, then BASIC? I'll agree with Dijkstra on that one!
Ok, about the pbm2df issue, I'll fix this eventually.
About -m, on Linux and BSD there's no such check because if you don't run DGen from a terminal, stdin will typically be redirected to /dev/null and the isatty() check in linenoise will assume a dumb terminal from which nothing will be read.
So in a sense the text console is always available. Remember it's currently only used by the debugger when enabled.
There's normally no "parent console" concept in Windows so I had to add a way to use the debugger without having to keep a console window opened when the debugger isn't necessary, hence the -m option.
No problem with printf(), however you will get mixed output (your own messages and DGen's in the same stream). This can be mitigated using dup() and fdopen() (which may not be implemented in MinGW) to create a separate stream.
gets() is a different story. During startup, DGen may read read its configuration file from stdin, then the debugger may also read it when enabled, so you should make sure to disable both first, otherwise you'll also need to open a separate stream using fopen(), since duplicating stdin like stdout won't solve the conflict.
Anyway, if you want interaction with a prompt, you should check how it's done in the debugger (with linenoise); you can probably reuse something in debug.cpp.
Hope this helps.
Hi !
Thanks a lot, Zamaz.
Finally, i think i'll make a separate shell : simple, portable… I'll try to make it feel like Amstrad CPC464. It will be used to launch the emulator and modify player-programs, even while the emulator is running. Then, user can press F7 or F8 to reload bot1 or bot2 code directly, without restarting the game.
I already have my "spriter" : when F4 is pressed, the game is paused and you can get the sprites' hashes that player-bots will use to "recognize" sprites. It works fine !
Just to be sure : how many bytes should i hash ? Right now i pick :
info.tw*info.th*4*(8 << info.inter) chars
…starting from (info.tile). Does it look ok to you ?
Cool. Your formula looks correct.
Hi!!
My first bot is running right now ! It pd_messages "hello world" every ten seconds...
And it's not BASIC anymore ;)
Brand new site !! http://progadrive.free.fr
What do you think ?