IRC logs for #opendune on OFTC at 2010-10-20
⏴ go to previous day
11:43:15 <zear_> i just found this project while browsing sourceforge, and will have two questions about it
11:44:22 <zear_> i read that this project was written in C using SDL, does that mean it should be easily portable to mips linux devices?
11:45:15 <Xaroth|Work> I think TrueBrain is probably the most knowledgable to answer that one
11:46:04 <zear_> and second question, i have never played dune II (i know, shame on me), but does dune II (or opendune) support 320x240 resolution? I am interested in porting it to a mips 320x240 device
11:46:21 <Xaroth|Work> iirc Dune II was at 320x240
11:46:35 <Xaroth|Work> opendune is (iirc) scaling it up to double size
11:46:45 <zear_> if this project is using only C and SDL, it should be portable to anything, but if it has any x86 asm stuff, it's a no go
11:47:21 <zear_> Xaroth|Work: ah, sounds great then, if it's scaling 2x, it means i can modify it to draw in 1x
12:01:35 <Xaroth|Work> zear_: Dune 2 dates back a looooooooong time, heck, it used to be available on floppy disks :P
12:04:05 <zear_> Xaroth|Work: i know, i was told it (or dune 1) was ported to amiga and megadrive
12:05:03 <zear_> so what's the status of opendune? Is it fairly playable?
12:05:23 <zear_> i was unable to run the linux x86 binary from the website
12:05:28 <zear_> gonna have to compile it myself
12:09:49 <Xaroth|Work> it should be able to run
12:09:53 <Xaroth|Work> ofcourse you need the dune 2 datafiles
12:10:03 <Xaroth|Work> and dune 2 has been ported to the amiga and megadrive yeh
12:10:18 <zear> yes, i have the datafiles, made sure they're lowercase
12:10:31 <zear> when i launch the binary, black window appears for a moment
12:10:50 <zear> and it's not chmod issue, as i even tried to run it from root
12:11:33 <zear> don't mind the ALSA errors, i currently have no sound card installed
12:11:47 <Xaroth|Work> yeh, that might be a cause tho :p
12:11:56 <Xaroth|Work> glx: that sound familiar?
12:12:35 <glx> hmm let me check something
12:13:46 <zear> this is the binary from 0.3 release
12:14:08 <zear> so i should try svn instead?
12:15:26 <zear> about the game itself, the platform i want to compile it for has no mouse nor touchscreen. I'll have to implement a simple mouse emulation with keyboard, though, does the game use two mouse buttons, or only left one?
12:16:06 <zear> and, i am also limited just to few buttons on this device, so 4 would be for moving the cursor around, one to act as a mouse click, any more buttons i need?
12:16:38 <glx> a full keyboard for security check
12:17:07 <zear> maybe will be able to nick an on screen keyboard from some other sdl projects
12:17:27 <zear> ok, i see the 0.3 src doesn't want to compile for me
12:17:43 <zear> says something about no rules for compiling libemu.so
12:18:49 <glx> you need libemu project too
12:19:08 <zear> ah, thought libemu would be built-in
12:19:18 <zear> the readme said i need only C and SDL ;)
12:19:41 <zear> libemu be better portable ;)
12:20:34 <zear> so the game simply emulates the dos exe?
12:34:00 <zear> glx, the same black screen with the svn build
12:34:50 <zear> no idea yet, the window is still on
12:44:03 <zear> i found my datafiles with dosbox, it's v1.7
12:45:03 <Xaroth|Work> er, no idea actually :P
12:45:13 <Xaroth|Work> there should be a link on our forums pointing to the right one
12:45:24 <zear> because it has files for different european languages
12:46:37 <zear> as it's titled Dune II: The Building of A Dynasty
12:46:44 <zear> while i need: Dune II: The Battle for Arrakis
12:47:08 <glx> the version is shown at bottom right of main menu
12:47:18 <zear> glx, it was only v1.7 i believe
12:47:31 <Xaroth|Work> 1.7 was the last version iirc
12:47:51 <zear> eh, i can only find the eu version in .exe format
12:48:04 <zear> would like some which i don't need use dosbox for to install
12:48:08 <zear> as it's slow and takes time
12:49:26 <zear> aah, thank you very much
12:51:08 <zear> well, still the same black screen problem
12:53:02 <zear> maybe it's sound problem indeed
12:53:14 <zear> will try to port it to my mips device later to see if it works on it
12:53:17 <zear> but for now, have to go, bbl
12:53:22 <zear> and thanks for all the help
12:53:27 <glx> for now you can edit config.c
12:54:23 <glx> (disables sound and music)
13:01:04 <zear> glx, nope, that's not a sound issue :/
13:05:17 *** tolbin has joined #openDune
13:50:47 *** ChanServ sets mode: +v Xaroth
13:50:47 *** ChanServ sets mode: +v Xaroth|Work
15:32:52 <zear> glx, i wiped out the previous installation and downloaded + built the svn version again
15:33:17 <zear> disabled the audio support in config.c, but still the same black screen issue
15:33:38 <zear> looks like some problem with date?
15:37:39 <glx> I don't think it's related to date
15:37:48 <zear> hmm.. weird, now launched it with gdb
15:37:55 <zear> fist it showed the black screen
15:38:04 <zear> so left it running and went do something else
15:38:16 <zear> when i returned i have a static picture of tanks and the "The insidious Ordos"
15:38:24 <zear> could be that my pc is too slow to play opendune?
15:39:30 <zear> this is quite a slow machine
15:39:49 <zear> the mips platform i want to port it to has 366MHz and 32ram, so it's even worse ;)
15:40:44 <zear> though currently i try to run opendune on my 900mhz x86 pc
15:41:21 <zear> hmm.. the game reacts on some keypresses, or at least it prints the message [EMU] ERROR: unhandled key * when i press them
15:41:28 <zear> but the image in the sdl window is static
15:41:56 <glx> well you can't skip intro on first run
15:42:19 <glx> just touch data/onetime.dat
15:42:19 <zear> should it be animated, or static images one after another?
15:42:36 <glx> static images with some animated parts
15:43:07 <zear> don't see any animations
15:43:31 <zear> gdb doesn't print any useful info, besides the game exits ok when i close the window, so there's nothing to debug with it
15:43:36 <zear> gonna switch to strace again
15:44:51 <glx> that's what it should look like
15:45:36 <glx> of course without voices, there is text on the screen :)
15:45:41 <zear> the game is not frozen, as it reacts on keypresses during the black screne
15:45:56 <zear> looks like a terrible cause of fps performance
15:46:13 <zear> the game uses only 38% of my cpu though
15:46:22 <glx> possible, it uses one full core of my athlon 64 X2 3800+
15:46:34 <zear> ouch, sounds like it won't run on my mips platform
15:47:09 <zear> well, was hoping something like dune, especially written with C and SDL, will be mor efficient ;)
15:47:24 <zear> does it do any dos emulation?
15:47:42 <glx> but it's probably due to the emulation layer (and the fact all the game is in a while(true) loop without sleep
15:47:58 <glx> libemu is dos emulation yes
15:48:07 <zear> hmm.. sounds like it won't run at all
15:48:18 <zear> we have dosbox port with heavy mips asm, yet it's so damn slow, nothing can run on it
15:48:50 <zear> if there's a way to set the game to run in 320x200/240 i can try to compile and run it though
15:51:27 <zear> nope, the game window starts up in a greater res
15:51:39 <zear> i'd say 640x480, maybe 800x600
15:54:42 <zear> then scaled, i need 1x scale as if i try any other res than 320x240 the game will simply segfault
15:54:52 <zear> (on my mips machine, that is)
16:10:56 <zear> hmm.. opendune is now running for a good 20min, without any effect on the screen
16:12:45 <zear> does that indicate that the game is up and running?
16:14:15 <zear> well, indeed this time it doesn't print key presses on stdout
16:14:33 <zear> but freeze or not, every time i launch it i have a black screen and nothing else
16:15:17 <zear> yes, this looks like a freeze, as it doesn't react on SDL_QUIT or ctrl + c
16:15:46 <glx> hmm it should still react to ctrl-c
16:18:31 <zear> ok, got it running this time
16:19:07 <zear> i can see the in-game cursor (rather than default SDL one), but it does not react on mouse click
16:22:05 <zear> ok, this is weird, the game progresses only when i minimize the game window
16:22:48 <zear> it doesn't look like the current surface is not being refreshed, because i can move the mouse cursor just fine and can see it's icon
16:23:12 <zear> but if i click something, nothing happens until i minimize the window, wait few seconds, and maximize it again
16:23:13 <TrueBrain> sounds like v-sync misses :)
16:24:08 <zear> so it could be nothing with my low spec system (900MHz)?
16:27:40 <TrueBrain> or maybe SDL is just incredible slow ...
16:27:46 <TrueBrain> what OS is running under it?
16:28:17 <glx> maybe an 8bpp on 32bpp issue too
16:36:09 <zear> sdl is in version 1.2.14-r2
16:36:14 <zear> runs fine all the other apps
16:36:15 <TrueBrain> x86_64 or x86 i686?
16:36:59 <zear> the official 0.3 binaries and self compiled svn
16:37:28 <zear> yes, the ones from the opendune forums
16:37:47 <TrueBrain> are there data files on the forums? Hmm ..
16:38:44 <zear> the final platform i wanted to run opendune on is a 336MHz (jz4740), 32RAM mips device, though now i think if it's so slow on my 900MHz x86, it won't run on that at all
16:39:14 <TrueBrain> mostly because of the not-yet converted code
16:39:20 <TrueBrain> runs via an emulator layer
16:39:44 <zear> does that mean that in the future all the code will be natively executed?
16:40:04 <glx> converted code is "native" yes
16:40:47 <glx> DOS layer is bypassed when a function is converted
16:40:56 <TrueBrain> what glx says :) There is just an additional layer which can use removing .. should speed up most things, but most of all: should remove the infinite loop
16:41:19 <zear> i'd like to at least attempt to run opendune on my mips target
16:41:21 <glx> TrueBrain: or at least add a sleep ;)
16:41:28 <TrueBrain> as far as your problem goes, it should work on a 900 MHz
16:41:29 <zear> though i'd need to know what to modify to run the game unscaled, in 320x200
16:41:34 <TrueBrain> there is no reason for it not to
16:41:52 <TrueBrain> there is pixel scaling in the INT10 handler of the emulator layer
16:42:10 <TrueBrain> if you have SDL on the MIPS, you can make SDL do the scaling
16:42:19 <TrueBrain> otherwise, you will have to write your own video output anyway
16:42:27 <zear> TrueBrain, we have no hardware scaler, and the sdl one is slow
16:42:44 <zear> plus i don't think there's a need to first scale it up, then scale it down
16:42:45 <TrueBrain> get to run first, optimize later ;)
16:42:59 <glx> you can modify int10 handler in libemu if you really need to
16:43:21 <zear> glx, yes, i'd like to, do i need any knowledge of dos to do that?
16:43:36 <glx> no, it's just simple logic :)
16:43:37 <TrueBrain> euhm, no, of course not. Only of C
16:43:42 <zear> if that's something simple like scale = 1; i should be able to do so :D
16:44:17 <TrueBrain> it is a loop-unfolded double-scale algorithm
16:44:20 <TrueBrain> those cannot be easier :p
16:45:01 <glx> comment some lines and change some increments, that's all
16:55:54 <zear> which one should i change, there's a lot of case [hex] depending on the screen modes
16:58:30 <zear> ok, let's see if it works
16:59:29 <glx> don't forget emu_int10_gfx (for the size of the window)
17:00:43 <zear> since libemu has setvideomode, the game does not have it anymore and i don't need to change window size in opendune's code?
17:01:07 <glx> the game thinks it runs in full screen :)
17:01:21 <glx> remember, it's a DOS game
17:04:53 <zear> well, the game crashes, i did something wrong ;)
17:08:31 <glx> you only need 1 *gfx++ = *data;
17:08:44 <zear> right, because i don't need double res
17:08:51 <glx> other were to draw 4 pixels for 1
17:09:20 <zear> so lines 9 and 10 are out, which one is the 3rd to be removed?
17:11:36 <zear> well, the good thing is the vsync problem is finally gone
17:11:59 <zear> the bad thing, while the game window is 320x240, the resolution is still somewhat scaled
17:13:12 <zear> looks like Y draws only every second row
17:13:28 <zear> so X res is ok, Y draws every second line black
17:14:00 <TrueBrain> you most likely have a ++ too many :p
17:16:02 <zear> TrueBrain, that helped, thanks
17:16:14 <Xaroth|Work> ooh funky lines :p
17:16:37 <Xaroth|Work> makes the harvester look proper massive too :P
17:16:45 <glx> mouse handling needs fixing too :)
17:18:07 <glx> 320x200 is definitely too small on 1680x1050 :)
17:18:07 <zear> TrueBrain, looks like 1x scale makes the whole thing run faster on low spec pcs, maybe you should consider this option official?
17:18:33 <zear> glx, well, you can always go fullscreen with that
17:18:45 <TrueBrain> zear: CPU-wise, there is very little difference
17:18:46 <zear> will be faster than 640x480 fullscreened
17:19:08 <TrueBrain> although it could be done slightly more optimal to ensure cache-hits
17:19:32 <TrueBrain> either way, the layer is just a temporary place holder for the conversaion to 'real' C to happen
17:19:45 <zear> glevans2, yeah, mouse still thinks i'm 640x480
17:21:42 <TrueBrain> one slightly issue only, mouse-code in DOS assumes the X or the Y (can't remember which) is double in size
17:22:24 <TrueBrain> int10.c, line 687 btw
17:22:45 <TrueBrain> most likely: 'x * 2' and 'y'
17:28:12 <zear> yep, it works now, thanks
17:28:39 <zear> this looks rather fullspeed
17:28:50 <TrueBrain> it drains your CPU :D
17:28:51 <zear> gives me hope that it might be actually playable on my mips platform
17:29:37 <zear> oh i don't mind, my mips platform displays sdl on the framebuffer, so there's a low chance of two different processes running at once
17:29:57 <zear> not counting the system ones
17:32:07 <zear> ok, libemu builds fine for mips
17:32:50 <glx> (if it builds for windows it should build for everything ;) )
17:33:15 <TrueBrain> well, I had to do a lot of hacking to get it to work on Microblaze :D
17:33:47 <glx> IIRC the main problem left for libemu is BE support
17:33:56 <TrueBrain> pain in the ass to get it right
17:34:06 <TrueBrain> got it to work in the end :D
17:34:49 <zear> TrueBrain, any non C/SDL problems with it?
17:35:18 <TrueBrain> and ther eis no SDL for Microblaze
17:35:20 <TrueBrain> so I had to be creative
17:35:31 <zear> that's why the curses in libemu?
17:35:52 <TrueBrain> that is for the non-graphical games
17:36:05 <zear> interesting, what games does libemu support?
17:36:34 <TrueBrain> it is not so much what libemu supports, more what the decompiler does :)
17:36:54 <glx> indeed, decompiling is the important part
17:36:56 <TrueBrain> snipes for example runs in non-gfx, and 'works'
17:36:59 <zear> is this method faster/slower than dosbox (or even comparable?)
17:37:20 <TrueBrain> this decompiles and outputs C code
17:37:24 <zear> this is like dynamic recompilation thing?
17:37:25 <glx> libemu does only what's needed
17:37:31 <TrueBrain> but to avoid also decompiling the whole of DOS
17:37:35 <TrueBrain> we put a layer in between to do that for us
17:38:00 <TrueBrain> (also a layer to do i386 instructions)
17:38:06 <zear> so basically as long as there are no nasty libs in between, i could recompile a game for dos and compile it for let's say mips linux?
17:38:50 <zear> i know of guys who did the "static recompilation" of warcraft 1, with arm linux as their target platform
17:39:07 <glx> the slowing part is the i386 emulation
17:39:09 <TrueBrain> static decompilation is nearly impossible with most applications
17:39:12 <zear> i don't know much about that things, but is this the same thing as static recompilation?
17:39:19 <TrueBrain> this because compilers do tricks to avoid static decompilation
17:39:54 <TrueBrain> (most change stuff dynamicaly, which alters a jump in the begin of the applications, making static decompilations to fail)
17:40:11 <glx> dune2 is a good example :)
17:40:22 <zear> dosbox for mips uses dynamic recompilation
17:40:26 <TrueBrain> I made a decompiler which is mostly based on dynamic decompilation, with tricks from static decompilation :D
17:40:42 <TrueBrain> does not decompilation of any kind, let alone recompilation
17:40:44 <zear> well, it says it has a dynrec mips core
17:41:02 <zear> it's what a lot of emulators for different platforms use
17:41:06 <glx> DOSBox just follows opcodes
17:41:13 <TrueBrain> DOSBox has the capability to alter a i386 instruction to any other instruction which does the same
17:41:16 <zear> but then again, i'm only repeating stuff, i know nothing about that things
17:41:36 <zear> ./opendune: ELF 32-bit LSB executable, MIPS, MIPS32 version 1 (SYSV), dynamically linked (uses shared libs), not stripped
17:42:20 <zear> hmm.. SDL_SWSURFACE | SDL_HWPALETTE
17:42:24 <zear> what does the second flag do?
17:42:31 <zear> we have only SWSURFACE support on my platform
17:42:34 <TrueBrain> use the hardware palette where possible
17:42:50 <TrueBrain> even leaving it out works I believe
17:42:59 <zear> ok, will check this one first them
17:43:00 <TrueBrain> just 99% of the video cards have hardware palettes :D
17:43:24 <TrueBrain> well, video cards = video chipset
17:43:32 <zear> then yes, i believe it must have something :D
17:43:42 <TrueBrain> but SDL on such platforms are mostly broken :p
17:43:59 <zear> it's linux, sdl works great on it
17:44:11 <TrueBrain> those 2 have little related :)
17:44:34 <TrueBrain> its a car! Of course it has a nice sofa
17:44:43 <zear> so far been able to run all the 320x240 sdl apps on it
17:45:14 <TrueBrain> but okay .. is it really a MIPS chipset?
17:45:23 <TrueBrain> MIPS is kind of ... 'nice in classroom'
17:45:44 <zear> and the platform is Dingoo A320
17:46:03 <TrueBrain> ah, that explains :)
17:46:10 <TrueBrain> ARM is the future, MIPS is dead :p
17:46:29 <zear> jz family still releases new cpus
17:46:43 <TrueBrain> yeah, stuff tends to have problems staying dead :)
17:46:47 <zear> though most of the handheld devices are arm nowadays, i agree
17:47:02 <TrueBrain> MIPS is RISC, but a bit too much RISC :p
17:47:07 * zear has a couple of arm ones if anyone's willing to try opendune on them)
17:47:12 <TrueBrain> ARM at least implemented some (cheap) additions :)
17:47:20 <TrueBrain> OpenDUNE works on ARM
17:47:25 <TrueBrain> at least someone runs it at some ARM
17:47:37 <TrueBrain> ARM9 most likely .. so I am not sure about ARM7 :)
17:48:06 <TrueBrain> the only true dep we have, is SDL and a small snippet of bleh
17:48:15 <zear> means it might actually run on my stuff
17:48:20 <TrueBrain> (the timer, that is)
17:48:54 <TrueBrain> there is little standard for interrupt timers :(
17:49:28 <zear> returns to menu, how nice ;)
17:49:50 <TrueBrain> OpenDUNE can run in 1MB, but I believe atm it needs 4 or something
17:50:10 <zear> i have 32 here, 20ish free
17:50:30 <TrueBrain> so it should work on all systems, in theory
17:50:43 <zear> segfault after the first two [emu][init21:3D]
17:50:49 <zear> sounds like a problem with sdl flags
17:50:52 <TrueBrain> and as it is pure C (ISO-C, ANSI-C, C89, how ever you want to call it), it should compile on all platforms .. in theory :p
17:50:54 <zear> gonna change that pallete to sw
17:51:23 <zear> and set the game window to 320x240, just to be sure it's not crashing due to a not supported res (it has a 320x240 lcd)
17:51:26 <TrueBrain> segfault can be a lot of things :p
17:51:39 <zear> yes, but if it happens so early it usually means sdl problem
17:51:48 <zear> i had it many times with different games i ported
17:51:50 <TrueBrain> but at least the core works
17:51:55 <TrueBrain> else you would never seen those two lines :)
17:52:55 <zear> would something happen if i removed the HWPALETTE flag and not replace it with SWPALETTE?
17:53:17 <TrueBrain> I tihnk it doesn't matter
17:53:29 <TrueBrain> it won't kill your machine (or at least, it really shouldn't)
17:53:34 <zear> yeah, as i expected, no such thing as SDL_SWPALETTE
17:53:44 <zear> so i have no way but to remove that flag completely
17:54:51 <zear> i guess just linking the binary with a new libemu is enough? Or i need to recompile the whole game again?
17:55:09 <TrueBrain> depends if you made a static or dynamic link :)
17:55:13 <TrueBrain> but 'make' will show you :)
17:55:18 <zear> hmm.. dynamic, so it's not even needed
17:55:31 <TrueBrain> it shouldn't be needed, no
17:56:11 <TrueBrain> HWPALETTE should work on all platforms
17:56:22 <TrueBrain> it just ensures we get true colours, even if SDL needs to emulate stuff for it
17:56:30 <TrueBrain> otherwise palette colours can fail
17:56:45 <TrueBrain> btw, don't forget to indicate you want fullscreen
17:56:49 <TrueBrain> might be a problem otherwise :)
17:57:18 <TrueBrain> and SWSURFACE or HWSURFACE, we really don't care :)
17:58:03 <zear> my platform doesn't support HWSURFACE, so i believe also the rest of HW*
17:59:11 <zear> let me charge it up a little and i'll try to debug it
17:59:30 <Xaroth|Work> and don't forget to supply patches for useful stuff :)
18:00:00 <zear> if i ever manage to run it, yep ;)
18:00:29 <zear> in the meantime i'll recompile it for x86 and check if the absence of HW_PALETTE makes a difference
18:02:07 <TrueBrain> HWPALETTE appears to have nothing to do with the hardware, that is: if the hardware doesn't know it, SDL emulates it :p
18:02:14 <TrueBrain> it just ensures us that colours are as they should
18:02:17 <TrueBrain> so it shouldn't matter :p
18:02:22 <TrueBrain> in worst case everything is black :p
18:04:57 <zear> for my platform i need 320x240, SWSURFACE and preferably 16bpp, though sdl converts 8 to 16 automatically
18:08:17 <zear> TrueBrain, any moment during the initialization that the game does not run in 0x13 mode?
18:08:40 <zear> i'm gonna hardcode 320, 240 to the setvideomode just to be sure they don't shift during the run
18:11:19 <TrueBrain> the only other mode is non-gfx
18:11:26 <TrueBrain> but that is not initialized
18:12:32 <zear> hmm, 320x240 without HWPALETTE seems to work fine on x86
18:12:48 <zear> let me quickly debug the mips version and i'll be going
18:14:37 <TrueBrain> guess you can disable the XMS
18:14:45 <TrueBrain> as long as you don't use sounds, that is no issue
18:14:49 <zear> ok, will play with it later
18:15:41 <TrueBrain> int2f.c, line 16, change 0x80 to 0x01
18:26:49 *** fjb is now known as Guest35
18:38:02 <zear> TrueBrain, seems to be working now :)
18:38:17 <zear> i can see westwood logo on screen
18:38:32 <zear> it is a bit slow, but that's just the intro
18:39:55 <zear> TrueBrain, hmm.. the rest of the intro seems to be rather fast
18:40:01 <zear> depends on what's happening on the screen
18:40:20 <zear> the pixel-by-pixel fade effect is very slow
18:40:28 <zear> but the animations are fast
18:41:50 <zear> now gonna need some sort of mouse emulation to choose the fraction and get to the real gameplay
18:42:05 <TrueBrain> (Well, normal is a big word, but .. it true on all platforms)
18:42:26 <TrueBrain> I believe we compiled most support for that
18:42:28 <zear> wait, you say it is fully controllable without a mouse?
18:42:34 <TrueBrain> just very nagging to control the game then :)
18:42:38 <zear> what about without qwerty? :P
18:42:45 <TrueBrain> Dune2 was created in a time mouse was optional
18:42:55 <zear> i have only about 8 buttons + dpad :D
18:43:11 <zear> yeah, it's a gaming handheld
18:43:15 <TrueBrain> 4 commands per unit
18:43:16 <zear> Dingoo A320, check the google pics
18:43:27 <TrueBrain> then you also have 2 menu entries
18:43:35 <zear> yes, dpad is already mapped to SDL_LEFT/RIGHT/UP/DOWN
18:43:36 <TrueBrain> and that leaves 2 to cylce through the units
18:43:45 <TrueBrain> should be 'sufficient'
18:43:48 <TrueBrain> although very annoying
18:44:01 <zear> keep in mind you need one button for mouse click
18:44:19 <zear> well, they made the megadrive port, didn't they?
18:44:43 <TrueBrain> I don't know if they did :)
18:48:49 *** ChanServ sets mode: +v Yexo
18:49:14 <zear> ok, added a mouse emulation deamon
18:49:28 <zear> but when i move the mouse out of the game window, the game crashes
18:50:16 <zear> "Program termination: jumped to 22A6:1063 which is not decompiled"
18:50:35 <zear> gonna run it via telnet later to be able to copy the full log
18:50:45 <zear> instead of typing it manually from the screen ;)
18:52:04 <TrueBrain> so don't move outside the window :)
18:52:12 <TrueBrain> you hit a spot we did not decompile
18:52:18 <TrueBrain> someone should fix that (/me looks at glx :p)
18:52:55 <glx> hmm 22A6 is GUI related IIRC
18:53:07 <zear> TrueBrain, this is running on full screen
18:53:22 <glx> drawing "lib" is there IIRC
18:53:30 <zear> though if the mouse touches the edge of the screen, the game crashes
18:53:43 <zear> anyway, opendune seems to be fairly playable on Dingoo A320 :)
18:54:06 <TrueBrain> don't move outside the window!!
18:54:09 <zear> but just a little, and a lack of the mouse should benefit from it
18:54:23 <TrueBrain> and the game will get faster over time :p
18:54:25 <zear> not that easy, this is mouse emulation, if i hold the direction too long, the mouse speeds up and gets out of the screen
18:54:41 <zear> yes, plus without the mouse the slower gameplay is easier to control
18:55:00 <glx> it's unresolved stuff in emu_GUI_CopyToBuffer()
18:55:22 <TrueBrain> ah, so that function protects against out-of-screen events
18:55:30 <zear> i'd record a gameplay vid, but my main pc is in the repair, and this 900MHz one has toasted usb ports, so can't mount the camera to upload the vid :P
18:55:45 <glx> if ((int16)emu_cx <= (int16)0x0) { /* Unresolved jump */ emu_ip = 0x1063; emu_last_cs = 0x22A6; emu_last_ip = 0x1075; emu_last_length = 0x0026; emu_last_crc = 0xD3B0; emu_call(); return; }
18:55:48 <TrueBrain> zear: I am already happy to read it works
18:56:03 <zear> oh yeah, and expect me to port it to a lot of other shit
18:56:06 <TrueBrain> glx: run the game in the JIT and move with cursor the mouse outside the window :D
18:56:10 <zear> i have a lot of cool devices lying around ;)
18:56:25 <TrueBrain> if they run SDL, they should 'just run'
18:56:29 <TrueBrain> otherwise, it will be more painful :)
18:56:45 <TrueBrain> you could try OpenTTD too :p
18:56:52 <TrueBrain> unplayable at that resolution, but still :p
18:57:13 <Xaroth|Work> could be doable tho
18:57:13 <zear> openttd is unplayable at 320x240 because it wasn't designed for that res
18:57:20 <zear> it's not like that in the case of dune
18:57:36 <TrueBrain> OpenTTD has code for those resolutions
18:57:39 <TrueBrain> but I don't like it
18:57:47 <zear> you could make a 8x8 tileset for openttd and the game would be totally playable at 320x240
18:58:03 <zear> i know, i tried to run openttd on gp2x which runs 320x240
18:58:26 <zear> 640x240 (the resolution of jornada 720) makes openttd VERY playable though
18:58:35 <TrueBrain> OpenTTD without mouse is pointless anyway
18:58:42 <TrueBrain> Dune2 'might' work good enough
18:58:52 <glx> TrueBrain> glx: run the game in the JIT and move with cursor the mouse outside the window :D <-- without JIT it already doesn't crash for me
18:59:36 <glx> but maybe it's because windows prevent that already
18:59:52 <TrueBrain> yeah, I think that it is because of the X-axis
18:59:57 <TrueBrain> most likely allows 640
19:00:01 <TrueBrain> where normally it can only hit 539
19:00:06 <TrueBrain> or something silly like that
19:00:30 <glx> I reverted libemu changes anyway
19:00:58 <zear> TrueBrain, did i mention that Dingoo A320 has a tv-out? :D
19:01:24 <zear> so it means the same experience as on 1920x1200 pc with the scaler
19:01:38 <zear> jsut the tv does the scaling
19:02:03 <zear> isn't that how your scaler works?
19:02:15 <zear> or it does some sort of blurring?
19:03:26 <TrueBrain> did it look like it did any blurring, when you were removing those lines? :p
19:03:38 <TrueBrain> libemu has priority of around 0 :)
19:03:44 <TrueBrain> it works ... that is all :)
19:04:01 <TrueBrain> the idea is to finish converting the rest of the OpenDUNE code to real C
19:04:21 <zear> i am interested in that alleycat support
19:04:31 <zear> if dune works at that speed, alley cat should be even more playable
19:04:38 <zear> unless dune's mostly native now
19:06:44 <zear> hmm.. i guess my usb ports work, but give no current
19:06:52 <zear> so if i plug my camera it should work
19:06:58 <zear> let me make some quick pics then
19:08:21 <Xaroth> dune is quite a bit native already
19:09:27 <glx> Xaroth: but many parts are still not converted
19:10:02 <TrueBrain> and alleycat does not completely work
19:16:23 <zear> that are some crappy pics due to the light conditions here, but you get a general idea how it looks like on the Dingoo A320
19:16:39 <zear> no, i should contratulate you guys
19:16:42 <TrueBrain> I am very impressed how good our work works :)
19:16:44 <zear> for this awesome project
19:16:57 <zear> and also without your help i wouldn't be able to get it to work
19:17:03 <glx> good luck for the security check ;)
19:17:10 <zear> how often does it happen?
19:17:19 <Xaroth> twice after mission.. 2 and .. something
19:17:27 <TrueBrain> well, depends how often you play over, of course
19:17:28 <zear> are there any nonprotected *wink wink* copies of the game?
19:17:42 <TrueBrain> the security is easily bypassed from a coding point of view
19:18:19 <zear> also, apologise for the dust and fingerprints on my device, as you can see it's highly abused by me ;)
19:18:34 <TrueBrain> I am unsure if I can live with that ...
19:18:53 <zear> ok, what needs to be done to fully support Dingoo A320 is keyboard emulation
19:18:59 <zear> this deamon thingy is rather crappy
19:19:07 <zear> does not lock dpad and it still returns SDLK events
19:19:19 <zear> so while i move the cursor, the map also scrolls
19:19:33 <zear> becuase of the dpad being SDLK_LEFT/RIGHT/UP/DOWN
19:20:13 <zear> and this deamon would work only for dingoo, and i'm interested in giving the support of Ben Nanonote, GP2X, Wiz, Caanoo and OpenPandora platforms now since it works fine on the dingoo
19:20:39 <TrueBrain> I suggest to forget about the keyboard
19:21:12 <zear> keyboard as in onscreen one to type the protection?
19:21:30 <zear> i don't care about it now, need a way to control the cursor with SDLK_[arrows]
19:21:33 <TrueBrain> for such platforms, I think it is good to remove the protection
19:21:40 <zear> gonna check how they did it in fheroes2
19:21:56 <zear> unless you have an idea how to do it
19:22:53 <zear> nanonote and pandora both have qwerty, so i guess they would be fine, but an option to disable the protection would be welcome in general
19:23:10 <TrueBrain> and I am playing Minecraft, so I have no suggestions :D
19:23:27 <zear> i'm glad it doesn't work well on my linux box
19:23:41 <TrueBrain> with a lot of fog, it does here :p
19:23:45 <zear> otherwise i'd probably didn't have time to port opendune ;)
19:23:55 <zear> nah, it's keyboard input issues here
19:24:04 <zear> i guess it's the java issue
19:24:45 <zear> should i post something about my port on the forums?
19:24:58 <zear> or nobody really cares? ;)
19:27:14 <zear> about the malloc issues with XMS, any way to not have malloc issues and still have sound? :)
19:27:32 <TrueBrain> sound can do without XMS
19:27:50 <TrueBrain> and malloc maybe fails because we say there is always 32MB free :p
19:27:54 <TrueBrain> which clearly there isn't :)
19:27:54 <zear> well, gonna raise the volume
19:28:00 <zear> because i can't hear anything
19:28:09 <zear> yes, that would be the issue
19:28:11 <TrueBrain> you need alsa for sound
19:28:19 <zear> it's safe to say 15M is always free here
19:28:46 <zear> the problems with ram shortages start when the memory usage hits 20 something
19:31:42 *** DorpsGek` has joined #openDune
19:35:22 *** TinoDidriksen has joined #openDune
19:35:22 *** Xaroth|Work has joined #openDune
19:35:22 *** charon.oftc.net sets mode: +ovov glx glx Xaroth|Work Xaroth|Work
19:35:22 *** glevans2 has joined #openDune
19:35:22 *** proyvind has joined #openDune
19:35:42 *** tolbin has joined #openDune
19:35:58 *** Xaroth has joined #openDune
19:35:58 *** blathijs has joined #openDune
19:35:58 *** TrueBrain has joined #openDune
19:35:58 *** magnet.oftc.net sets mode: +vov Yexo Xaroth Xaroth
19:38:07 *** tolbin has joined #openDune
19:44:33 *** tolbin has joined #openDune
19:46:21 <TrueBrain> guess we survived that
19:47:46 *** DorpsGek has joined #openDune
19:47:46 *** ChanServ sets mode: +o DorpsGek
19:57:52 <zear> TrueBrain, no sound nor sfx here
19:58:13 <zear> disabled XMS would mean no sfx, but i can't hear music too
20:03:10 <glx> hmm alsa is for music, sound is done via SDL
20:03:40 <zear> you're using alsa for music, and not just sdl?
20:03:48 <glx> hmm or is it voices with SDL
20:03:57 <zear> which could then run on any sound system
20:04:21 <glx> MPU uses ALSA (MPU is the music)
20:04:52 <zear> hmm.. the game crashed when i tried to save it with a blank name ;)
20:05:29 <zear> (that will need some auto savestate name generation for my platforms)
20:07:00 <glx> you restored src/config.c ?
20:07:24 <zear> what were the default values?
20:08:57 <glx> so music and sound use the same driver
20:10:04 <glx> music is definitely midi so ALSA for music
20:12:53 <glx> voices use sound blaster (SDL)
20:13:27 <TrueBrain> music and sound uses mpu yes, which is alsa for linux
20:13:38 <TrueBrain> voices use SDL and need XMS
20:14:06 <glx> alsa + timidity if no hardware midi :)
20:14:18 <zear> why not timidity itself?
20:14:40 <glx> you can use whatever you want with aconnect
20:14:45 <TrueBrain> 2) using timidity directly is a biatch
20:14:53 <TrueBrain> 3) ALSA allows hardware support :)
20:14:58 <TrueBrain> and SDL doesn't know MIDI, so ..
20:17:09 <zear> that will be a problem for handheld devices, as most of them don't use alsa
20:17:21 <zear> and well, non-posix ones won't be even able to
20:17:51 <glx> MPU already has 3 implementations: ALSA, WIN32 and none
20:18:50 <glx> so it should be possible to add more (but we probably won't do it because it already wors for us ;) )
20:23:44 <zear> glx, expect me to bug you guys a lot in the future about missing features like that ;)
20:31:53 <zear> well, i'm off, will be back tomorrow to bug you some more ;)
continue to next day ⏵
