Who's Online |
142 user(s) are online ( 71 user(s) are browsing Forums)
Members: 1
Guests: 141
Georg,
more...
|
|
Headlines |
-
amiarcadia.lha - emulation/gamesystem
Mar 28, 2024
-
losmalditosdemo.lha - game/adventure
Mar 26, 2024
-
libfreetype.lha - development/library/graphics
Mar 25, 2024
-
ign-addon-ods.lha - office/spreadsheet
Mar 25, 2024
-
meminfo.lha - utility/hardware
Mar 25, 2024
-
libsdl2_ttf.lha - development/library/graphics
Mar 24, 2024
-
thf.lha - game/fps
Mar 24, 2024
-
amigagpt.lha - network/chat
Mar 24, 2024
-
liba52.lha - development/library/audio
Mar 23, 2024
-
libsdl2_mixer.lha - development/library/audio
Mar 23, 2024
|
|
|
|
Re: Freedroid 1.0 soon, make?
|
Posted on: 2019/10/5 14:42
#61
|
Quite a regular
|
@kas1e
Good to see it works for you.
The OpenGL mode needs GLEW which we don't have or I couldn't find it anywhere.
I know about the stack cookie stuff, I'm just lazy :)
@K-L Try this link but I also want to know if 0.16rc2 on OS4Depot has the same crash for you.
Edit: Updated binary using libSDL built by @kas1e Edit 2: Link removed.
Edited by MickJT on 2019/10/5 15:42:56 Edited by MickJT on 2019/10/11 6:09:33
|
|
|
|
Re: Freedroid 1.0 soon, make?
|
Posted on: 2019/10/5 7:59
#62
|
Quite a regular
|
I link it all statically to avoid problems with missing/mismatched sobjs. Can you also test it for me? Maybe it's just K-L having that issue?
|
|
|
|
Re: Freedroid 1.0 soon, make?
|
Posted on: 2019/10/5 7:51
#63
|
Quite a regular
|
@K-L
Does the old version on OS4Depot have the same crash? I'm curious. The stack trace points to libSDL. Are you running it from shell or double-clicking the icon? The icon should be setting a high stack before running the game. Make sure you're not mixing save files between the two. Does it work at 640x480?
Later tonight I'll link it against the latest libSDL. I'm currently using an older libSDL.
By the way I noticed the prob with the tutorial level also happens with the start of the main game, but it doesn't really matter there. The "Old Guy" is supposed to run up to you when you first start.
|
|
|
|
Re: Freedroid 1.0 soon, make?
|
Posted on: 2019/10/4 12:35
#64
|
Quite a regular
|
Any testers? Planning on uploading it tomorrow if there's no reports of any problems.
|
|
|
|
Re: Freedroid 1.0 soon, make?
|
Posted on: 2019/9/27 16:55
#65
|
Quite a regular
|
Here's a test archive. I have no idea if previous save files are still compatible (doubtful). Go into Performance Tweaks and adjust the settings there to improve the framerate.
The tutorial mission had a problem (broken in the last port too). I'm not sure exactly what the issue is, and it doesn't happen on Linux/Windows, but "Tutorial Tom" is supposed to automatically "rush" to your character, Tux, and open a beginning dialog chat box making partner_started() true, but that isn't working. It might be that the "rush" command is being unset automatically because of frame lag or something when starting the level (there is code to check if a bot has become "too aggressive").
I made a quick workaround in a .lua script to add the "rush" command the first time a dialog box is opened with Tutorial Tom, which you have to do manually. Certain gates are supposed to be closed at the beginning of the tutorial but they're open until that first dialogue screen which is supposed to be automatic. So, when you start the tutorial, click on Tom immediately before he walks off. You'll see an incorrect dialog box but another one will open and continue normally from thereon.
Temporary download link
Edit: Link removed
Edited by MickJT on 2019/10/11 6:10:08
|
|
|
|
Re: Freedroid 1.0 soon, make?
|
Posted on: 2019/9/26 9:31
#66
|
Quite a regular
|
This will be coming soonish. Still only SDL_gfx & software rendering, but very playable.
|
|
|
|
Re: Streaming twitch.tv on AmigaOS 4.1
|
Posted on: 2019/9/25 16:12
#67
|
Quite a regular
|
Just would like to chip in here. I had a look at the console log white sent me.
At the start of playback he sees "[AO SDL] Unsupported audio format: 0x1c."
Then it plays for a bit, then a bunch of HTTP error 400 Bad Request.
The “unsupported audio format” is nothing to worry about. It's when after the decoding of the compressed format, the now "raw" format is still unplayable by SDL/AHI. So it converts that to another raw format that is playable.
If you add -v to the command line, you can see this:
[libaf] Adding filter format [format] Changing sample format from big-endian 32-bit float to big-endian 16-bit signed int [format] Accelerated big-endian 32-bit float to big-endian 16-bit signed int conversion
The Bad Requests are most likely because it's not permitted by the server to fetch the very same link twice. Basically, MPlayer is doing something not permitted by the server. It's a bug, and out of my control/ability to fix.
|
|
|
|
Re: Downloads keep failing on OSDepot
|
Posted on: 2019/8/10 18:00
#68
|
Quite a regular
|
@orgin
When downloads fail for me, I've managed to get them successfully via the Swedish mirror.
|
|
|
|
Re: Paging salass00!
|
Posted on: 2019/8/5 18:34
#69
|
Quite a regular
|
Hmm. I didn't receive the reply. There's no auto-deletion spam filtering on. I'll send you another e-mail, just for testing purposes. Might just be some odd glitch? Hopefully. Thanks for letting me know. I'll upload it soon.
|
|
|
|
Paging salass00!
|
Posted on: 2019/8/5 8:07
#70
|
Quite a regular
|
I don't know what else I can do but make a forum post. I'm trying to get a hold of you. Emailed you last week and messaged you on here. Perhaps this will work :)
|
|
|
|
Re: Doom Sigil
|
Posted on: 2019/6/4 23:47
#71
|
Quite a regular
|
Are you supposed to have both files on the command line? The wad files are roughly the same size. The notes seem to imply the _COMPAT version is an alternative to the main one, for stricter ports. I haven't tried it myself yet. Edit: Yeah other forum posts just show only _COMPAT. Apparently listing Chocolate Doom in the notes was a mistake, and SIGIL isn't compatible with it: https://www.resetera.com/threads/john- ... edition-also.86203/page-4
|
|
|
|
Re: SDL2
|
Posted on: 2019/2/12 5:14
#72
|
Quite a regular
|
Seems like an out of date SDK? You need 53.30.
|
|
|
|
Re: SDL2
|
Posted on: 2018/12/14 1:27
#73
|
Quite a regular
|
@kas1e
Usually object files in .libs/ are those compiled with -fPIC, for the .so, and the ones in the parent directory are those without -fPIC, for the .a. The final .so and .a both end up in .libs/. That's the standard autotools+libtool way.
|
|
|
|
Re: e-uaes from os4depot, fresh recompile (post #10)
|
Posted on: 2018/11/25 9:03
#74
|
Quite a regular
|
@kas1e
I've compared them using diff, but I don't really know what I'm looking at to make a proper bug report. I don't know which change it is. All I can say is it's one of them, and my best guess is the change from rev 335 of adtools on sourceforge.
I'm not the best person to make a bug report about this. I have no altivec enabled machine, and therefore no way of testing binaries myself to create an easily reproducible test case, nor do I know whether it's only specific instructions that cause a problem. I've tracked it down to the linker scripts (internal & external) in binutils 2.23.2, but to find the exact instruction(s), and a proper test case, is too tedious for me and annoying for someone else if I have to send them countless binaries to test for me. Not to mention I don't think I'd even know how to create a proper test case. I don't know assembly, or even C for that matter. Best someone else debugs it :)
This is a bit off-topic now and doesn't relate to e-uae. As mentioned earlier, e-uae has no altivec specific code and so -maltivec is not required, but I only wanted to mention any problem that might arise if it was used. I think there is an effect when using that flag even when compiling code that has no specific instructions for it.
|
|
|
|
Re: e-uaes from os4depot, fresh recompile (post #10)
|
Posted on: 2018/11/24 11:16
#75
|
Quite a regular
|
@kas1e Without _ARCH_PWR4 defined (which also gets defined by -mcpu=970), then the JIT is very slow on X1000. See http://euaejit.blogspot.com/2012/10/jinxed-it-more-apples.html and http://euaejit.blogspot.com/2014/07/p ... dreds-and-xthousands.htmlNote that -mno-powerpc64 will be needed if you're going to use -mcpu=970, otherwise you'll get weird stuff like the mouse movements being inverted (see this link). As for the stuff I said in the e-mail about -maltivec, it just causes strange behaviour if linked with the current binutils. Not necessarily crashes, but just incorrect code execution. Using -N when linking fixes it, or manually using amigaos.x from an older binutils (i.e the one included in SDK 53.30) with -Wl,-T /path/to/file.x > And you probably build and generic version and x1000 one before with that flag ? That flag/definition is the difference between an X1000 and non-X1000 version, so there's no such thing as building a "generic" version with that flag. I probably confused you by talking about altivec flags in the email. There's no altivec code in e-uae, but I think the -maltivec flag was possibly used in Rachy's X1000 builds regardless, and I think it does have some minor effect even on code that has no specific altivec instructions, so I thought I'd let you know about any problems that might arise from using that.
Edited by MickJT on 2018/11/24 11:40:32 Edited by MickJT on 2018/11/24 11:47:25 Edited by MickJT on 2018/11/24 11:48:36 Edited by MickJT on 2018/11/24 11:49:44
|
|
|
|
Re: e-uaes from os4depot, fresh recompile (post #10)
|
Posted on: 2018/11/23 7:25
#76
|
Quite a regular
|
@kas1e
Check your email.
|
|
|
|
Re: Polaris - Mplayer problem
|
Posted on: 2018/11/6 3:05
#77
|
Quite a regular
|
I'm totally clueless on any of this sort of stuff, so despite it sounding easy, I'll probably get confused on what to do. I'll look at the linked page though.
|
|
|
|
Re: Polaris - Mplayer problem
|
Posted on: 2018/11/5 15:07
#78
|
Quite a regular
|
@Hans I'm not good at C. The vo_comp_yuv2.c I have is similar to the one on github: https://github.com/khval/mplayer-amiga ... /src/libvo/vo_comp_yuv2.cIt looks like the test you're talking about is already there. If I hard code "have_readeonhd" to TRUE (typo corrected in my source) as I've done in the test binary above, or was to remove that check altogether, it should still get to "if (have_compositing == FALSE)" and stop on machines that don't support it, however on my Sam Flex machine with a Radeon 9250SE, it passes that bitmap test, so have_bitmap_format and have_compositing are TRUE and I end up with a white window. Is the test being done wrongly?
|
|
|
|
Re: Polaris - Mplayer problem
|
Posted on: 2018/11/5 6:19
#79
|
Quite a regular
|
I've not tested this (nor am I able to). I just disabled the check for RadeonHD.chip in comp_yuv2. non-altivec build. https://www.sendspace.com/file/byyesp
|
|
|
|
Re: Polaris - Mplayer problem
|
Posted on: 2018/11/5 5:15
#80
|
Quite a regular
|
Does LiveForIt-MPlayer 6.5.7 work? http://os4depot.net/share/video/play/liveforit-mplayerng.lhaWhen using 6.4, check the shell output and see if it's really using comp_yuv2 or just comp_yuv (or just comp). Altivec or non-Altivec? Does it crash, freeze, or something else? DSI/ISI? Empty window? And do test LiveForIt-MPlayer 6.5.7. It's closest to mickjt-mplayer. @mufa You didn't mention which version of mplayer you were trying to run, and whether it's for altivec or not. Paste all the lines that say something like "VO: [somethinghere] text here". Version 6.4 doesn't have the same checks that later versions do. In later versions there is a check to see if RadeonHD.chip is being used, and I suspect that check is failing with RadeonRX. You'd then see something in the shell like: VO: [comp_yuv2] You need RadeonHD to use this video output.
Edited by MickJT on 2018/11/5 5:33:22 Edited by MickJT on 2018/11/5 5:44:14 Edited by MickJT on 2018/11/5 5:51:04 Edited by MickJT on 2018/11/6 0:06:29
|
|
|
|