Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
142 user(s) are online (71 user(s) are browsing Forums)

Members: 1
Guests: 141

Georg, more...

Headlines

Forum Index


Board index » All Posts (MickJT)




Re: Freedroid 1.0 soon, make?
Quite a regular
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
Go to top


Re: Freedroid 1.0 soon, make?
Quite a regular
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?

Go to top


Re: Freedroid 1.0 soon, make?
Quite a regular
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.

Go to top


Re: Freedroid 1.0 soon, make?
Quite a regular
Quite a regular


Any testers? Planning on uploading it tomorrow if there's no reports of any problems.

Go to top


Re: Freedroid 1.0 soon, make?
Quite a regular
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
Go to top


Re: Freedroid 1.0 soon, make?
Quite a regular
Quite a regular


This will be coming soonish. Still only SDL_gfx & software rendering, but very playable.

Go to top


Re: Streaming twitch.tv on AmigaOS 4.1
Quite a regular
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.

Go to top


Re: Downloads keep failing on OSDepot
Quite a regular
Quite a regular


@orgin

When downloads fail for me, I've managed to get them successfully via the Swedish mirror.

Go to top


Re: Paging salass00!
Quite a regular
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.

Go to top


Paging salass00!
Quite a regular
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 :)

Go to top


Re: Doom Sigil
Quite a regular
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

Go to top


Re: SDL2
Quite a regular
Quite a regular


Seems like an out of date SDK? You need 53.30.

Go to top


Re: SDL2
Quite a regular
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.

Go to top


Re: e-uaes from os4depot, fresh recompile (post #10)
Quite a regular
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.

Go to top


Re: e-uaes from os4depot, fresh recompile (post #10)
Quite a regular
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.html

Note 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
Go to top


Re: e-uaes from os4depot, fresh recompile (post #10)
Quite a regular
Quite a regular


@kas1e

Check your email.

Go to top


Re: Polaris - Mplayer problem
Quite a regular
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.

Go to top


Re: Polaris - Mplayer problem
Quite a regular
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.c

It 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?

Go to top


Re: Polaris - Mplayer problem
Quite a regular
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

Go to top


Re: Polaris - Mplayer problem
Quite a regular
Quite a regular


Does LiveForIt-MPlayer 6.5.7 work?

http://os4depot.net/share/video/play/liveforit-mplayerng.lha

When 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
Go to top



TopTop
« 1 2 3 (4) 5 6 7 ... 47 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project