Author Topic: Windows 64 bit SDL_gfx  (Read 10343 times)

0 Members and 1 Guest are viewing this topic.

JRS

  • Guest
Windows 64 bit SDL_gfx
« on: March 17, 2014, 12:05:41 AM »
Here is a SDL_gfx library example running under Windows 7 64 bit as a 64 bit application. (no WOW crap) Open source library resources are hard to find on Windows 64 bit and in most cases require a build from scratch.  :o




« Last Edit: March 17, 2014, 03:01:23 PM by John »

JRS

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #1 on: March 17, 2014, 10:44:55 AM »
I was able to build the Windows 64 bit version of the Script BASIC GFX extension module. It's interesting that Windows 7 64 bit takes twice as long as Linux 64 bit to complete the Mandelbrot example. XP (in a VirtualBox) and Wine was much closer to the Linux 64 bit execution time.

Note: These examples are using the same Script BASIC GFX scripts that were used for the Linux 64 bit and Windows XP 32 bit examples.





« Last Edit: March 17, 2014, 12:02:59 PM by John »

Aurel

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #2 on: March 17, 2014, 04:19:45 PM »
Yes Windows XP is faster than Win7 :P

JRS

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #3 on: March 17, 2014, 04:41:13 PM »
Quote from: Aurel
Yes Windows XP is faster than Win7

That's why they killed it.  :-X

XP is a great Windows VirtualBox OS. I have a virgin XP SP3 current with all updates as a master copy. I clone it as a fresh up to date XP install. This is where I will be doing all my Windows 32 bit stuff. Windows 7 64 bit is only for 64 bit development. I have no interest in 32 bit Windows emulated on current MS OS offerings. Windows 64 bit native applications already run at 1/2 the speed of their Linux counterpart. Why add an emulator as another layer? Personally I wish MS would have spent the effort maturing their 64 bit OS rather than wasting the energy on emulating and exacerbating the 32 bit realm that has been long overdue for the bone yard.


JRS

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #4 on: March 17, 2014, 06:04:59 PM »
I was able to get the Windows 64 bit version of  IUP working with the Script BASIC IUP extension module interface. I still need to get the manifest issue resolved but everything else looks fine.



I got the scribaw.exe version of Script BASIC built which is a Windows application and not a console app. It also includes what is needed for theming controls. Using the following command will generate a standalone Windows (no console support) version of your SB IUP app.

scribaw -Eo myapp.exe myapp.sb

« Last Edit: March 17, 2014, 10:44:00 PM by John »

Mike Lobanovsky

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #5 on: March 17, 2014, 08:03:00 PM »
I have no interest in 32 bit Windows emulated on current MS OS offerings. ... Why add an emulator as another layer? Personally I wish MS would have spent the effort maturing their 64 bit OS rather than wasting the energy on emulating ...

WoW64 is not an emulator, John. It is a subsystem, in fact, a sub-OS in its own right that uses the CPU and its cores natively through the sets of 32-bit instructions that the CPU supports alongside its 64-bit armory by design. Using WoW64 is basically the same as using a 32-bit XP on an x64 CPU, e.g. on an Intel Core2 Duo, which is exactly what I've been doing in the recent 5 years or so, without any abstraction layers in between. The CPU's hardware virtualization options are not engaged by, nor necessary for, the WoW64 subsystem.

The system and program modules including WoW64's kernel32.dll are all genuine MS software compatible, and in many cases even interchangeable, with XP's original modules.

Have you ever tried to run your 32- and 64-bit Windows 7 samples in the OS' Aero modes? The Windows 7 desktop's DirectX 9-based compositing window manager (DWM) is much more intricate than that of XP and it often seems much better optimized for Aero than for Classic and Basic (that's what you're using judging by your snapshots) DWM modes.

Next, the lag that you're getting with your samples may be due to improper implementations of linuxoid SDL/IUP/whatever modules on MS Windows platforms. Linux devs are usually not that bright in almost everything that relates to graphics and UI's, and this is true whatever you say in favor of your preferred OS, server-wise.

And finally, you cannot find open-source 64-bit code simply because the general x64 program base is still rather scarce against myriads of 32-bit applications available on the net. There are only a few thousand applications known to the entire Linux world and maybe tens of thousands 64-bit applications altogether, but there are virtually millions of them still available in the 32-bit flavor.

"The patient is rather more alive than dead", John. :)

JRS

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #6 on: March 17, 2014, 11:21:39 PM »
That's all well and fine but my client isn't the Red Cross serving the homeless and in crisis. My clients are small businesses that are making investments in their future and developing for hardware no longer main stream and OS's being retired makes it almost impossible of a story to tell.

« Last Edit: March 17, 2014, 11:55:32 PM by John »

Aurel

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #7 on: March 18, 2014, 05:45:02 AM »
Great explanation Mike  ;)
And yes what is native on linux graphics ..nothing
everything is emulated trough X-org,vesa ..etc..etc servers
there is no graphic or GUI sunsytem for linuxoid yet....

By the way your script basic is developed on 32bit linux ..right?
so how you create 64bit version using same old 32 bit code...
you probably use gcc 64bit version of compiler and compile old 32bit code with that
right?

JRS

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #8 on: March 18, 2014, 05:58:15 AM »
Quote
And yes what is native on linux graphics ..nothing
everything is emulated trough X-org,vesa ..etc..etc servers
there is no graphic or GUI sunsytem for linuxoid yet....

You're wrong and most online gaming services are Linux based. You should focus and comment about things you know about.

Quote
By the way your script basic is developed on 32bit linux ..right?
so how you create 64bit version using same old 32 bit code...
you probably use gcc 64bit version of compiler and compile old 32bit code with that
right?

Script BASIC is using one version of the ANSI C source for all platforms. (Windows, Linux, OSX 32/64 bit and Android (ARM) native)

Old code? Script BASIC has been an on going open source project for over 12 years. It's used commercially in embedded (firmware) controllers. I would say it's one of the most actively developed BASIC projects out there besides O2.

BTW: How is RubenDev coming along? Is this a remake of the Never Ending Story about being consumed by nothingness?

Aurel

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #9 on: March 18, 2014, 06:20:31 AM »
Quote
You're wrong and most online gaming services are Linux based.
I don't talk about online gaming services than about linux OS on desktop PC.

RubenDev is just a crappy experiment and nothing else.... ;D ;D ;D
somehing like many junks around

Mike Lobanovsky

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #10 on: March 18, 2014, 09:30:25 AM »
... most online gaming services are Linux based...

Again this isn't necessarily so, John. While there are a certain number of Android "games" around but neither are these games high-class nor can Android OS be called Linux without reservations. The games in question are primarily low-end free-to-play indie stuff based on the ideas from innumerous old-time Commodore, Amiga, and DOS Pacman-style game repos with slightly prettified character and HUD graphics. Android OS is to Linux basically what Darwin is to FreeBSD.

Wine's primary goal was, and still largely is, to allow Linux users to play MS Windows games in their lonesome terminal environments.

Serious gaming stuff, whether online or offline, remains pretty much desktop PC- and console-oriented. Complex picture-perfect action games require adequate immersive environments unavailable for multi-purpose handheld toy-gadgets and similar household utensils. Here Linux services can, but not necessarily do, fit in as a low-cost server-side back end for monitoring and controlling network traffic, user database management, logon and logoff protocols, payment collection, et cetera. Which of course is where Linux would belong in the first place. And this is also exactly where Linus Torwalds earned his $150M worth (hello you poor GNU GPL deadbeats, how ya doin'? ).

JRS

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #11 on: March 18, 2014, 11:30:50 AM »
Mike,

I'm not a gamer and only do business related (accounting / distribution / embedded interfaces) type programming. All I'm saying is MS is no longer the prominent OS and has to earn it's user base going forward. Steve Ballmer almost destroyed Microsoft and I compare him to the Bush, Rumsfeld and Cheney style of management. It has always amazed me how tolerant we have become allowing maniacs to determine our future.




JRS

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #12 on: March 18, 2014, 12:14:55 PM »
It has gotten to point if you want to program in BASIC, the prerequisite is that you write your own version of the language first.  I could care less what hobbyist are looking for in a BASIC. There are plenty of toy / wannabe BASIC language attempts out there cluttering the landscape for them to play with.







 

Mike Lobanovsky

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #13 on: March 18, 2014, 01:07:49 PM »
John,

I can but totally agree with your two last statements. :)

Charles Pegge

  • Guest
Re: Windows 64 bit SDL_gfx
« Reply #14 on: March 18, 2014, 02:48:20 PM »