| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Release id #185343 : VICE 3.4
Since 3.4 Mr Wegi's loader stopped working - it seems to init drive and go idle. Any solution to that? Tweaking settings gives no results. |
|
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Have they fixed the farting 8580 yet? I still have to run 2.4 to get a smooth and nice experience. |
| |
Dano
Registered: Jul 2004
Posts: 226 |
As i am building my own vice and following the svn updates i can't remember seeing anything that has to do with SID and fixes to the playback.
My biggest problem is the framerate under Windows. Neither on my private or my work laptop i get a proper 50FPS playback. And that doesn't add to improve sound playback even more.
As for SIDs i think i still resort to SidPlay2.6w as i think it sounds pretty good (Sidplay/w V2.6).
But i am no musician after all..
As for the Drive/Loader issues.. I didn't have any drive issues with the latest 3.3 builds running the somewhat latest Demos from time to time. Still i wouldn't know what to tweak or alter for a different drive behaviour. |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: As i am building my own vice and following the svn updates i can't remember seeing anything that has to do with SID and fixes to the playback.
My biggest problem is the framerate under Windows. Neither on my private or my work laptop i get a proper 50FPS playback. And that doesn't add to improve sound playback even more.
As for SIDs i think i still resort to SidPlay2.6w as i think it sounds pretty good (Sidplay/w V2.6).
But i am no musician after all..
As for the Drive/Loader issues.. I didn't have any drive issues with the latest 3.3 builds running the somewhat latest Demos from time to time. Still i wouldn't know what to tweak or alter for a different drive behaviour.
It has mostly been an issue with 8580 emulation when running sid's with thick base, like Linus' tunes or Jammer's. Then the base "farts", since Vice 3.1. When poking the devs about it, they want more detailed technotalk specifications, which I cannot provide. |
| |
Stone
Registered: Oct 2006
Posts: 168 |
Quoting dano
My biggest problem is the framerate under Windows.
I haven't compiled the latest versions of VICE/resid, but I know from experience that tweaking the floating point settings for resid-fp has a tremendous impact on performance (5x speedup and more). The default settings with the Microsoft compiler will create slow code. If you have VS2019 you can even use llvm/clang. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
@hedning: sound works cool in 3.4 :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Quoting StoneQuoting dano
My biggest problem is the framerate under Windows.
I haven't compiled the latest versions of VICE/resid, but I know from experience that tweaking the floating point settings for resid-fp has a tremendous impact on performance (5x speedup and more). The default settings with the Microsoft compiler will create slow code. If you have VS2019 you can even use llvm/clang.
VICE's build system hasn't supported MSVC for quite a while now. If you want to build VICE on Windows from source you'll need msys2, unless Visual Studio supports autotools projects. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Quoting JammerSince 3.4 Mr Wegi's loader stopped working - it seems to init drive and go idle. Any solution to that? Tweaking settings gives no results.
Groepaz pointed me to the cause - virtual devices (emulator settings) must be disabled. Case closed.
Thanks! |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Well, that was easy =) |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: @hedning: sound works cool in 3.4 :)
Great! |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: Quoting StoneQuoting dano
My biggest problem is the framerate under Windows.
I haven't compiled the latest versions of VICE/resid, but I know from experience that tweaking the floating point settings for resid-fp has a tremendous impact on performance (5x speedup and more). The default settings with the Microsoft compiler will create slow code. If you have VS2019 you can even use llvm/clang.
VICE's build system hasn't supported MSVC for quite a while now. If you want to build VICE on Windows from source you'll need msys2, unless Visual Studio supports autotools projects.
How can we get them to do that again then? The bulkyness of today's versions is unbearable. 95% of the daily VICE users must be Windows users. |
| |
Perplex
Registered: Feb 2009
Posts: 254 |
Quoting hedning95% of the daily VICE users must be Windows users.
True. People on Linux use VICE mostly during the night. |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: Quoting hedning95% of the daily VICE users must be Windows users.
True. People on Linux use VICE mostly during the night.
Haha! :D |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
Quoting hedningHow can we get them to do that again then? The bulkyness of today's versions is unbearable. 95% of the daily VICE users must be Windows users. 1. Become one of "them".
2. Fucking do it.
3. Keep doing it.
=) |
| |
hedning
Registered: Mar 2009
Posts: 4595 |
Quote: Quoting hedningHow can we get them to do that again then? The bulkyness of today's versions is unbearable. 95% of the daily VICE users must be Windows users. 1. Become one of "them".
2. Fucking do it.
3. Keep doing it.
=)
What would I do there? Pixel a new icon? Become Groepaz’ personal spacepresser? :D |
| |
Hein
Registered: Apr 2004
Posts: 933 |
Quote: @hedning: sound works cool in 3.4 :)
Been using 3.3, SID emulation sounds more accurate than reSID fp, which I used before and didn't reveal the low filter clickers for 8580. |
| |
Jammer
Registered: Nov 2002
Posts: 1289 |
Quoting HeinBeen using 3.3, SID emulation sounds more accurate than reSID fp, which I used before and didn't reveal the low filter clickers for 8580.
True, given SID filter has burnt a little xD That said - direction was right only slightly overdone. |
| |
Radiant
Registered: Sep 2004
Posts: 639 |
Re: SID filters — the problem lies/lied in the formula used for replicating the analogue filter in the 8580 not accurately reproducing the filter curve as measured from a real C64, when fed the constants used in the ReSID sources. I submitted a tentative patch that made the filter sound more correct to my delicate ears, though the curve was still way off. Not sure if that patch ended up being used, if a proper fix was made, or if the new filters were simply redisabled for the 8580 until they could be made right. More info may be available among the bug reports in the Sourceforge project.
Re: Windows builds — why even bother supporting MSVC if MSYS/MinGW works? The difference in the resulting binaries is likely completely negligable, and building using one is in no way harder than building using the other. |
| |
Stone
Registered: Oct 2006
Posts: 168 |
Quoting Radiant
Re: Windows builds — why even bother supporting MSVC if MSYS/MinGW works? The difference in the resulting binaries is likely completely negligable, and building using one is in no way harder than building using the other.
It's not just about spitting out an executable. I hear VICE team is still looking for maintainers on Windows and Mac and in order to contribute, most people will probably want a development experience they are comfortable with. Why not use a platform independent build system (or build system generator) like cmake, which seems to be becoming an industry standard for C/C++ based projects these days?
I only have a single VICE patch to my name (a crash bugfix related to midi), but to make it happen I had to jump through some hoops to create Visual Studio project files so I could debug it. Having up-to-date build files for other OSes would greatly lower the bar for contributing. BTW: I don't love cmake. I just hate it a little less as time passes by. |
| |
iAN CooG
Registered: May 2002
Posts: 3132 |
> Why not use (etc)
because they don't want to do it themselves, you have to jump in and volunteer on doing it. |
| |
Krill
Registered: Apr 2002
Posts: 2839 |
> Why not use a platform independent build system (or build system generator) like cmake, which seems to be becoming an industry standard for C/C++ based projects these days?
> because they don't want to do it themselves, you have to jump in and volunteer on doing it.
In my experience, because all of them are shit. If done right, plain makefiles can be just as platform-independent and remain highly flexible and well-documented. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Plain Makefile's will do fine with projects using little to no external libraries and when you only support a few OSes and a single compiler. Command line things like an assembler can be done with plain Makefile's and perhaps a bunch of #ifdef's to handle platform-dependent code.
I prefer plain Makefile's too, when feasible, I'm not a fan of autotools, but so far it's the most logical thing to use for us, seeing the amount of OSes, libraries and compilers we need to support.
I've tried a lot of build systems, one even suggested cat'ing .c files together to speed up compilation =)
We dumped MVSC support because it was a pain in the arse to maintain: basically a whole lot of brittle scripts going through the source to create MVSC crap and nobody used it.
I'm not saying I'll never consider another build system, but in the end it comes down to people actually willing to put in the work to show buildsystem X, Y or Z is better. And then maintain it. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting hedningQuoting CompyxVICE's build system hasn't supported MSVC for quite a while now. If you want to build VICE on Windows from source you'll need msys2, unless Visual Studio supports autotools projects. How can we get them to do that again then? The bulkyness of today's versions is unbearable. 95% of the daily VICE users must be Windows users.
So what gives you the idea this has anything to do with supporting MSVC? Vice is written in C, and Microsoft's compilers don't support newer C standards at all -- they seem to only care about C++. Nowadays, it makes no sense at all to support building a C project with MSVC. You use either GCC or LLVM/clang, both are available in MSYS2 for Windows :)
I have no idea whether the VICE code base actually uses any C99 and newer language features, but that's generally #1 reason for kicking out MSVC support. #2 is probably the burden to maintain multiple build systems.
As for performance issues of recent VICE versions built for Windows, I never really noticed them myself, but I don't use it a lot on Windows and the Windows machine I use has a pretty fast CPU ...
Any idea whether these issues are more likely in VICE's code or in other libs / build settings / etc? I could maybe try to create a build using my MXE toolchain and see whether it uses less CPU ;) |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting CompyxPlain Makefile's will do fine with projects using little to no external libraries and when you only support a few OSes and a single compiler.
Well, you *can* do more complex stuff, especially if you don't restrict yourself to "portable make" but require a specific flavour like e.g. GNU make.
Because I don't like the huge complexity of GNU autotools, I started developing my own system using only GNU make "metaprogramming" here: https://github.com/Zirias/zimk :)
Don't get me wrong, I would never suggest a complex project like VICE adopting this, of course it doesn't have all the features GNU autotools provide, and it totally lacks in documentation -- but I *do* use it myself, so just mentioning it here as an example what can be done with "plain make". E.g. it handles dependencies with pkg-config :) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
VICE uses some C99 features, such as the fixed with integer types (stdint.h) and bool (stdbool.h). I tried to use the new printf format specifiers in inttypes.h, but the Windows C runtime doesn't support those, so in stead of:
size_t x = 42;
printf("%zu\n", x);
I have to revert to the old C89 'trick' to print a size_t:
size_t x = 69;
printf("%lu\n", (unsigned long)x);
Perhaps '%llu' and `unsigned long long` on 64-bit, if Windows even supports that, haven't checked yet.
We have a way of generating a CMake project from trunk, which should be importable into VS, I'm not sure how useful that would be seeing the abominable state of MS's C support.
I tried the CMake route with VS, but I got a lot of missing .lib files for Gtk3 etc. There's supposed to be a tool 'vcpkg' to install those libs for use in VS, but on my box VS didn't see the libs, leading to manually adding a lot of libs using a horrific UI, so I deleted VS. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting CompyxVICE uses some C99 features, such as the fixed with integer types (stdint.h) and bool (stdbool.h). I tried to use the new printf format specifiers in inttypes.h, but the Windows C runtime doesn't support those, so in stead of:
size_t x = 42;
printf("%zu\n", x);
I have to revert to the old C89 'trick' to print a size_t:
size_t x = 69;
printf("%lu\n", (unsigned long)x);
Perhaps '%llu' and `unsigned long long` on 64-bit, if Windows even supports that, haven't checked yet.
There are two ways around this when using MinGW to link to MSVCRT.DLL.
1. Do something like this:
#include <inttypes.h>
#include <stdio.h>
#ifdef _WIN32
# ifdef _WIN64
# define PRI_SIZET PRIu64
# else
# define PRI_SIZET PRIu32
# endif
#else
# define PRI_SIZET "zu"
#endif
int main(void)
{
size_t mySize = 24;
printf("%" PRI_SIZET "\n", mySize);
}
2. Let MinGW link some code to your executable working around this by adding
#define __USE_MINGW_ANSI_STDIO 1
I'd assume %lu could break on 64bit windows, as a size_t is probably 64 bits wide, but a "long int" still has only 32bit (Windows 64bit uses the LLP64 data model, unlike most Unixes that use LP64)
Quoting Compyxso I deleted VS.
Unless you want to create .NET code, best course of action ;) |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Interesting. I'll try the first option first, since we also cross-compile Windows bins on a Debian box.
The second option appears to require some additional fuckery, and it probably won't work with VS (not that I personally care).
And yes, deleting VS felt pretty good :=) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
what do people use in lieu of VS? |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I use Vim and a terminal. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Same here. And there are many other nice text editors with coding support (e.g. "vs code") if you *really* don't like vim.
And for those in need of a full-blown IDE, there are several alternatives as well (e.g. eclipse, although I think that's a monster, but there are others as well) |
| |
oziphantom
Registered: Oct 2014
Posts: 478 |
sadly VSCodes C/c++ support is x86 only.
Eclipse is a horror show, a text editor should be instant on anything with 3 or more Ghz, and it fails.
SlickEdit supports linux(they have a Raspberry Pi beta now it seems).
the true power of VS however is the debugger, that is what I would like a linux version of.
Edit-and-continue would also be sweet. |
| |
Zirias
Registered: Jan 2014
Posts: 48 |
Quoting oziphantomsadly VSCodes C/c++ support is x86 only.
Ok, I never used it, but I thought it's just a code *editor*? How can this be specific to an architecture?
Quoting oziphantomEclipse is a horror show, a text editor should be instant on anything with 3 or more Ghz, and it fails.
That's why I didn't mention it as example for an editor but for a full-blown IDE (and probably the largest possible alternative there ... smaller ones exist as well).
Quoting oziphantomthe true power of VS however is the debugger, that is what I would like a linux version of.
I once used the gdb integration in "Qt Creator", which worked pretty well. So, there are working solutions for sure if you want "GUI" debugging. Almost always, I just use gdb or lldb directly at the console and I don't miss anything either... |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
are you sure its a nice feature that the emulation keeps going while the user is in the settings ? I think one would prefer to stop the game/demo until he tweaks the settings to his likings. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
Use Alt+P and then Alt+O |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
works, but now I have to pause manually while so far it was automatic.
fex someone plays a game he is near hi score, and notices joystick settings are wrong, or whatever, do you want the game go on while looking at the menus to fix your problem?
humans can not multitask I can either do the menus or look at the emulation...
:( |
| |
Oswald
Registered: Apr 2002
Posts: 5017 |
oh but thanks for the tip, atleast there is a work around. |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
I've added (optionally) pausing the emulator when opening the settings dialog in r38292. When active, the emulator is paused when the settings dialog is shown, and when closing the dialog, the old pause-state of the emulator is restored.
To toggle the setting, use the "Pause when showing settings" checkbox in the bottom left corner of the settings dialog. |
| |
Frantic
Registered: Mar 2003
Posts: 1627 |
How much did he pay? |
| |
Compyx
Registered: Jan 2005
Posts: 631 |
That's private ;) |
