Jump to content

revelator

Development Role
  • Posts

    933
  • Joined

  • Last visited

  • Days Won

    19

Everything posted by revelator

  1. well the old operating systems could actually run on modern pc's if it wasnt for a few snags... there are no sata drivers for them (yes you are f.... by now so no need to go further), no GFX or soundcard drivers as well. Luckily you can still get some 3rd hand used hardware for peanuts that supports the above, go for a mainboard with AGP to get the best compatibility, but you can actually run 98 on a core2 with the PCIE gen2 if you can find an lga 775 board with the old PATA header you are golden, still need to be carefull with gfx cards but the old geforce 6 or 700 models still had win9x drivers even for PCIE. try to get your hands on one of the older soundblaster cards preferably one using a PCI socket. Remember win9x cannot use ram above 3gb so put no more than 4gb in the board as it would be a waste, also fat32 has some restrictions on harddrive size though most PATA models should be ok to use. Something like the above was the last win9x machine i had and except the fact that drivers had to be installed in the correct order (if you dont it will crash and you can start all over again) and you had to be carefull with some software also (around that time microsoft enforced driver signing you might guess why after you tried this setup). It was fast though really really Really fast when it worked...
  2. ill try to spruce it up sometime later with a 1680v2 xeon, this cpu has 2 more cores though it also clocks a little lower than my 3930k 3 ghz vs 3.2 but is unlocked and the turbo frequency is a bit higher 3.9 vs 3.8 and can be overclocked to the same levels. it is also based on ivy bridge so can use gen 3.0 pcie without hacks with the nvidia card. tdp is also a bit lower than the old sandy :), it does not support avx2 but neither does mine and does not matter much anyway since avx2 gives a roughly 5% boost.
  3. here we go https://epicgametech.com/too-old-in-2020-nooot-i7-3930k-x79-gtx-1080-gaming-pc-build-14-benchmarks-power-usage/ he was actually using the 1080 non ti model to get these numbers xD
  4. hmm seems im not alone in getting some impressive results with this old setup paired with the 1080 ti, some other guy did this with a setup that was much like my own, his x79 board was not quite as flashy as my old asus x79 deluxe (he used a gigabyte board) but the cpu was not botllenecking it in the least :). ill see if i can find the article again he also benchmarked this setup.
  5. actually im on 3.0 i know the nvidia driver forces 2.0 with this cpu normally so i used the force enable gen 3 tool they provide, cooler is a windforce the 1080 ti i got is from gigabyte.
  6. btw this card is paired with an old 3930k shows how little the cpu matters when the resolution goes up.
  7. finally upgraded my aging 980 ti to a 1080 ti and woooot... i can run hzd in ultra in 4k with around 60 fps now blinks also tried metro 2033 but that one does not run to well in ultra 4k i get around 29 fps. the evil within 2 gets loads more than 60 fps in 4k so nice the witcher 3 also happily chucks along at around 75 fps. what i find most impressive though is that the card even at ultra settings at 4k newer goes above 55 degrees, my old one at 1440 would hit 85 to 90 degrees on some of the heavier titles above.
  8. turned out the broken mutex locking mechanism was also the culprit causing TDM-GCC to not be able to use ASLR i now have a fully ASLR and DEP compatible build of it. yes the image below is graphviz built by my TDM compiler and yes it (and all dependencies) use adress space layout randomization. Still a ways to go rebuilding all the packages from MSYS2 but slowly getting there. MSYS2 has tons of libraries and tools geared toward anything you can imagine (several game related), for one it has a full build of the godot engine, ogre3d, irrlicht, openscenegraph, blender (only 64 bit), and all the imaging libraries you can imagine. Also a vulkan loader glslang and hlslang compiler.
  9. had one of these beauties as well https://www.classic-computers.org.nz/collection/ps2-70.htm years ahead of microsoft by the time, ran microsoft stuff as well using a port of the win 3.11 subsystem. probably one of the best workspace operating systems of the time though it did use quite a bit more resources than 3.11 it was not slow at all. it did have some quirks though.
  10. amd's ryzen certainly hit a stride id argue that things would have looked very differently for consumers if intel had been the only player on the market eg. (multicore cpu's would have come a lot farther in the future and 64 bit also, while prices would have been a lot higher).
  11. the users dont own anything, it is all leased with a wording that implies ownership but in reality it can all be taken away on a moments notice if the powers that be decide it (sad truth but the truth non the less), in the end most wont be hit by that fact cause in the end when we die we loose it all anyway
  12. ok well the threadripper is one beastly cpu omgawd... strangely it does not translate to a better gaming experience, my old board actually runs things smoother than the threadripper. where it shines is when doing multiple cpu intensive tasks like running the msys2 compiler to rebuild the whole slew of packages avaliable for it. on my old board this took days... the threadripper munches that down to hours woa!!!. next up is raising dough for a newer gfx card, the 980 gtx ti i got hold of has been holding up nicely but i just got a 4k monitor and just running in UHD resolutions allmost fry it... in fact it gets so hot that i use it to heat my 52 m2 flat atm, ambient temperature hits around 24" with this running
  13. updating games from my childhood heh should not be to hard as the first ones i played was on the spectrum zx 80 -> most were text based hehe. one of the few graphical ones was pong which was a black and white ping pong game with two bars one in each corner standing in for bats. Maybe updating it to a color scheme hmmmmmmm... but since you mention it should probably be possible to add some more umph to the original they hunger using xashxt which is the modder extension for xash3d, supports shaders / bumpmapping / advanced particles fresnel etc.
  14. forgot one thing in WaitForSingleObject you can not use an "if" to get the wait value doing so causes a segfault instead use a "while" or use a case switch, had to create a test program to try out the functions and it repeatedly segfaulted untill i did that change. works better than ever now older versions of the patch only used one such mutex lock instead of two and mostly worked but sometimes it caused some oddities which it seems was because the mutex lock newer worked to begin with.
  15. i live in denmark strange every board i can find from here seems to be seriously expensive no matter the search engine Oo blinks. the cheapest i was able to find was an asus prime 399x for 472 dollars used.
  16. older than that im afraid was a 1950x so 16 core 32 threads not 24 cores and only board i seem to be able to get is with the 399x chipset, still way better than what i had but the boards for this one cost some serious dough
  17. welp well got the cpu for a good deal but the mainboard for this puppy will set me back atleast 4000 dollars guess i have a new paperweight untill i win the lottery
  18. well seems my latest iteration of the patch managed to fix the buggers i had with gdk-pixbuf2 and ogre they now work just fine looks like parsing the acl's and setting permissions accordingly on the mutex was all that was needed, only seems to be a problem if using win10 so something tells me that they started getting serious about security features in the windows api.
  19. the original did not even use mutex locks instead it used the CTOR DTOR mechanism from the crt to decide when to run it, was also a whole lot messier to read and the code for enabling it for the C++ exception handler was rather crude (only supported throwing abort on error) incidently both the terminate_handler and unexpected_handler of this shared the same code which funny enough gcc reverted to with the latest version since c++17 does not support unexpected at all.
  20. not exactly unofficial as said it was used for years doing the grunt work with the now defunct mingw.org compiler (and cygwin) and it worked pretty well back when we could not even build the dll's on windows. Ofc the complexity of gcc has multiplied since those day's so it had to be updated to reflect that. Debugging atleast told me it was crashing in the mutex locking mechanism, so after a whole lot of reading about mutexes in general i went to work and it is quite stable now except with those few sources. That said i might be in over my head from here on because the debugger tells me those are crashing in ntdll.dll but not what it is that is crashing them :S i only get a stack trace. the most funny thing and something which was not done originally is that the shared pointers code only runs when linked to the static runtimes it does not run when linked to the shared runtimes so should not affect things built using that, but even that does not work for said sources... crashes with the exact same error so it might not even be where i think it is.
  21. so far out of the hundreds of packages currently supported by msys2 mingw-w64 it builds about 99% and about 97% of them work, current offenders are gdk-pixbuf2 (or maybe one or more of the libraries the loader code links against) ogre3d (sometimes works strangely ?!?) and ofc gimp or any other gtk based package that relies on the gdk-pixbuf2 loaders. Strangely gtk2 gtk3 and gtk4 all work fine so im a bit stumped by this.
×
×
  • Create New...