Does anyone still use dos zsnes?

[jdratlif]

Maybe if the ZSNES Team focuses MORE on the Linux and Windows Ports,
there will be more frequent releases.

The ZSNES Team tries not to focus on any ports. We're considering dropping Win32 support so we can be completely portable too.

Well that's just stupid. If the ZSNES team was worried so much about portability, it should have not choosen assembly language to begin with.

It's kinda dumb now to all the sudden say we don't care about specific ports, we're more focused on portability. What a joke.

There's a major difference between portability and maintainability.

also, pagefault and I are not the original ZSNES Team, we actually have different ideas than the original team.

It also bothers us that as it currently stands, ZSNESW can't be compiled freely.

Ah.. that's the operating word here. Maintainability is indeed different. But you didn't say that.

I realize you two aren't the original team. I jump the gun sometimes. It was wrong to go back to the beginning language choice, but in the same sense, pagefault has been on the team for years and all the sudden NOW he's interested in portability? I just think trying to focus on portability at this point is fruitless.

If you replace portability with maintainability, then i have no beef!

On a side note. I'm learning towards the opinion that you're going to have some negative results switching to SDL in windows as opposed to DirectX. I wouldn't think it would run quite as fast.

Then that would of course cause me to go off on another stupid rant about all the optimizations for speed that have been doen to ZSNES over the years and then all the sudden there is a unnecessary step backwards in speed.

You shouldn't "learn" towards any opinion. Learning opinions is bad. Try to lean toward one instead. (God I hope I don't make any spelling errors during this post

On to something substantive. I don't think the SDL port would necessarily be any slower than the DirectX port. That would suggest that either DirectInput is faster (or more responsive anyway) than SDL, or that DirectX is faster than OpenGL. Neither of which I think are true. But I have no benchmarks to back me up, so maybe I am wrong.

[Nach]

Ah.. that's the operating word here. Maintainability is indeed different. But you didn't say that.

I meant make one of our three ports more portable for the sake of maintainability so we don't need the other two.

pagefault has been on the team for years and all the sudden NOW he's interested in portability?

Lots of things have changed in the past few years. Such as pagefault and I pretty much agreeing that Linux is the best OS except where gaming is concerned. In such a case, it would be better to develop the port best suited for Linux, and make it compatible where the other one or two used to be. Interestingly enough, _Demo_ also seems to want to return to ZSNES a bit and is now using Linux a lot as well.

Will it happen? I don't know, I'll be very happy when we release v1.40.
If we do go through with a GUI change and improving the SDL port, you can be sure a lot of things will be happening with ZSNES which will move it towards portability too.

Here's some log:

Oct 08 00:10:39 <pagefault> yeah demo wants to overhaul zsnes
Oct 08 00:10:48 <Nach> what is _Demo_'s plans?
Oct 08 00:10:54 <Nach> he's returning to ZSNES?
Oct 08 00:10:56 <pagefault> remove dos support
Oct 08 00:11:00 <pagefault> and modularize everything
Oct 08 00:11:02 <pagefault> new gui
Oct 08 00:11:02 <pagefault> etc
Oct 08 00:11:08 <Mexandrew> w00t?
Oct 08 00:11:26 <pagefault> basically bring it into the 21st century
Oct 08 00:11:27 <Nach> when does he plan on doing this?
Oct 08 00:11:45 <pagefault> dunno
Oct 08 00:11:48 <pagefault> he wants to do it though
Oct 08 00:11:55 <GeneralLeoFF> proly the normal zsnes pace
Oct 08 00:11:56 <Nach> I want to do it too :/
Oct 08 00:12:14 <pagefault> we basically don't want zsnes to fade away
Oct 08 00:12:17 <Nach> but I'd probably write a program to do it for me before I do that
Oct 08 00:12:41 <pagefault> but to do what he wants to do dos won't be supported anymore
Oct 08 00:13:03 <GeneralLeoFF> it;s worth it I would say
Oct 08 00:13:07 <Nach> if we can compile with MinGW, and bring all ports onto equal footing, I wouldn't mind
Oct 08 00:13:12 <GeneralLeoFF> ZSNES needs it
Oct 08 00:13:13 <pagefault> yeah
Oct 08 00:13:18 <pagefault> _Demo_ uses linux most of the time now anyway
Oct 08 00:13:22 <Nach> remove the DOS/Win32 specifics
Oct 08 00:13:23 <pagefault> so he is all for open compilers
Oct 08 00:13:36 <Nach> start using SDL, OpenGL and what not
Oct 08 00:14:06 <pagefault> because dos is antiquated
Oct 08 00:14:11 <pagefault> and contains 16-bit code
Oct 08 00:14:15 <pagefault> which wouldn't work
Oct 08 00:14:38 <ipher> SDL doesn't work in DOS, does it?
Oct 08 00:14:54 <pagefault> it works in dos on paper
Oct 08 00:15:01 <pagefault> but what that means in the real world is unknown
Oct 08 00:15:18 <GeneralLeoFF> you could proly get it working under DR-DOS 8
Oct 08 00:15:22 <GeneralLeoFF> but screw it
Oct 08 00:15:25 <pagefault> i'm sure the dos version of sdl isn't well maintained
Oct 08 00:15:40 <ipher> yea
Oct 08 00:15:53 <pagefault> we would probably drop sdl for video
Oct 08 00:15:55 <pagefault> and use gtk
Oct 08 00:16:09 <pagefault> if we go with a gtk gui
Oct 08 00:16:17 <Nach> how about OpenGL and we draw a GUI?
Oct 08 00:16:30 <pagefault> thats too complicated
Oct 08 00:16:40 <GeneralLeoFF> and it;s part of why the old gui should go
Oct 08 00:16:49 <GeneralLeoFF> it's resorce heavy sometimes
Oct 08 00:16:50 <pagefault> too hard to maintain
Oct 08 00:16:58 <Nach> that's what we did till now :/
Oct 08 00:17:03 <GeneralLeoFF> the gui in zsnes seems slow
Oct 08 00:17:29 <GeneralLeoFF> it's a dos gui not a windows gui is all
Oct 08 00:17:30 <Nach> but it's sequential
Oct 08 00:17:52 <pagefault> gtk has fast a fast graphical backend
Oct 08 00:17:57 <pagefault> and we don't have to worry about double buffering or anything
Oct 08 00:18:03 <pagefault> since thats all handled automatically
Oct 08 00:18:04 <GeneralLeoFF> I like GTK GUIs
Oct 08 00:18:18 <Nach> how portable are we going to make ZSNES?
Oct 08 00:18:26 <pagefault> it will work on windows and linux
Oct 08 00:18:34 <pagefault> and other x86 unixes
Oct 08 00:18:37 <pagefault> thats probably it
Oct 08 00:18:40 <Nach> will anything aside from core emulation be x86?
Oct 08 00:18:54 <pagefault> no
Oct 08 00:18:59 <pagefault> everything else will be portable
Oct 08 00:20:09 <Nach> great
Oct 08 00:20:30 <Nach> which basically means we're not far from being really portable at that point
Oct 08 00:20:43 <Nach> since we already have some special chips in C, etc...
Oct 08 00:21:44 <pagefault> you'll have to ask Demo for more info
Oct 08 00:21:49 <pagefault> he didn't go into much detail

[Agozer]

Wow. talk about overhaul.

[Shogetsu]

I'm curious... what about wxwidgets (previously known as wxwindows)? have you looked at it? or is SDL better?

[Nach]

Sure, let's compare Windows to PC Hardware.

[LDAWG]

Wow! this is great news.
I can't wait to see the future of ZSNES.
ZSNES is damn near one of the best things in my life, right now.
Thanks again guys, for keeping the SNES Hardware alive!

[Shogetsu]

Sure, let's compare Windows to PC Hardware.

Ehm... wxwindows works on near every platform and OS, despite the name (confusions like this one are the main reason because of the name change to wxwidgets)...

[Nightcrawler]

Ah.. that's the operating word here. Maintainability is indeed different. But you didn't say that.

I realize you two aren't the original team. I jump the gun sometimes. It was wrong to go back to the beginning language choice, but in the same sense, pagefault has been on the team for years and all the sudden NOW he's interested in portability? I just think trying to focus on portability at this point is fruitless.

If you replace portability with maintainability, then i have no beef!

On a side note. I'm learning towards the opinion that you're going to have some negative results switching to SDL in windows as opposed to DirectX. I wouldn't think it would run quite as fast.

Then that would of course cause me to go off on another stupid rant about all the optimizations for speed that have been doen to ZSNES over the years and then all the sudden there is a unnecessary step backwards in speed.

You shouldn't "learn" towards any opinion. Learning opinions is bad. Try to lean toward one instead. (God I hope I don't make any spelling errors during this post

On to something substantive. I don't think the SDL port would necessarily be any slower than the DirectX port. That would suggest that either DirectInput is faster (or more responsive anyway) than SDL, or that DirectX is faster than OpenGL. Neither of which I think are true. But I have no benchmarks to back me up, so maybe I am wrong.

Hmm.. my only comeback is close your parenthesis! How lame.. Ok I lose.

SDL would be slower than coding with OpenGL directly I'd imagine. I don't have any direct SDL experience, so I'm just speculating.

I agree with your other points. Input should be equal and speed for the most part. Sometimes poor video card drivers cause OpenGL to be slower sometimes, but that doesn't mean OpenGL is slower.

[funkyass]

i'd perfer WxWidgets over gtk.

and SDL isn't really at the same level of functionality as DX. I think all the input improvements made with the switch to DX8 would be lost.

they intend it to be modular, so a native Win32 API GUI wouldn't be out of the question.

[Nightcrawler]

Ah.. that's the operating word here. Maintainability is indeed different. But you didn't say that.

I meant make one of our three ports more portable for the sake of maintainability so we don't need the other two.

Ok.. that makes more sense.

pagefault has been on the team for years and all the sudden NOW he's interested in portability?

Lots of things have changed in the past few years. Such as pagefault and I pretty much agreeing that Linux is the best OS except where gaming is concerned. In such a case, it would be better to develop the port best suited for Linux, and make it compatible where the other one or two used to be. Interestingly enough, _Demo_ also seems to want to return to ZSNES a bit and is now using Linux a lot as well.

I've seen Linux just as much as XP! As soon as you start to use an OS GUI, it starts to be just like Windows.
My experience is mainly with RedHat though.

Will it happen? I don't know, I'll be very happy when we release v1.40.
If we do go through with a GUI change and improving the SDL port, you can be sure a lot of things will be happening with ZSNES which will move it towards portability too.

Ok, here's my gripe with this huge plan. It's going to take a long time to do this. And in the end, you're still left with ZSNES in it's current state.

All this time could be used to actually fix some bugs that have been around for several years and/or work on the timing engine rather than all this superficial fluff.

However, I realize that I am in no position to dictate to anyone what they should or should not be doing with their free time. If you all choose to do this than so be it. I just hate to see the man power of three ZSNES team members be used for fluff

[jdratlif]

Ah.. that's the operating word here. Maintainability is indeed different. But you didn't say that.

I realize you two aren't the original team. I jump the gun sometimes. It was wrong to go back to the beginning language choice, but in the same sense, pagefault has been on the team for years and all the sudden NOW he's interested in portability? I just think trying to focus on portability at this point is fruitless.

If you replace portability with maintainability, then i have no beef!

On a side note. I'm learning towards the opinion that you're going to have some negative results switching to SDL in windows as opposed to DirectX. I wouldn't think it would run quite as fast.

Then that would of course cause me to go off on another stupid rant about all the optimizations for speed that have been doen to ZSNES over the years and then all the sudden there is a unnecessary step backwards in speed.

You shouldn't "learn" towards any opinion. Learning opinions is bad. Try to lean toward one instead. (God I hope I don't make any spelling errors during this post

On to something substantive. I don't think the SDL port would necessarily be any slower than the DirectX port. That would suggest that either DirectInput is faster (or more responsive anyway) than SDL, or that DirectX is faster than OpenGL. Neither of which I think are true. But I have no benchmarks to back me up, so maybe I am wrong.

Hmm.. my only comeback is close your parenthesis! How lame.. Ok I lose.

SDL would be slower than coding with OpenGL directly I'd imagine. I don't have any direct SDL experience, so I'm just speculating.

I agree with your other points. Input should be equal and speed for the most part. Sometimes poor video card drivers cause OpenGL to be slower sometimes, but that doesn't mean OpenGL is slower.

He he. I actually thought about the parenthesis thing, but I keep forgetting that it replaces my ) in my smilies with pictoral smilies. And I thought the double )) would look weird. Of course since it does the pictoral smilie (emoticon, whatever), I should have.

You cannot code OpenGL without an underlying window system. OpenGL is completely platform independent. It only lets you draw things on the screen. This means you cannot write an OpenGL program unless you use a windowing toolkit as well. SDL is definitely the most popular, but there are others. glut was a piece of crap, but it predates SDL iirc.

The fact that you can choose to not use OpenGL with SDL does not mean SDL is slow.

However, that brings up another issue. SDL is a platform independent window toolkit. It has nothing to do with standardized GUI controls. This means you get a window, and control of the IO devices with SDL, but it won't make you a menu or a toolbar or a button, etc.

This is the only reason DirectX is nice. It's a giant repository of everything you would ever need. Windowing toolkit, graphic primitives (ala OpenGL -- is that the right term 'ala'? I don't think it uses OpenGL. I think vendors support two standards because Microsoft backs one and everyone else backs the other, but I could be wrong. Been a long time since I took gfx, and we only did OpenGL), and a GUI toolkit using the windows standard interface.

GTK, I believe, is a combination GUI toolkit and windowing system. This would give it a slight advantage over SDL from a developer standpoint, assuming you cannot using GTK widgets from an SDL window system. I don't know all the specifics. I've only barely begun to examine SDL and GTK (someday I'ld like to write programs that use GUIs that aren't Java).

Conversely however, there is already an SDL implementation of the input and window systems in zsnes. This means, assuming again that you might not be able to use GTK widgets from an SDL window, that they would have to throw away nearly all platform work and start from scratch on the GUI and input side.

While this would not be the most daunting task (the core would be much harder I think), it is certainly not an easy task.

Some time ago, I was teaching myself C++. I was rewriting into Java lessons in C++. But I couldn't quite get the graphics all figured out. There just wasn't any easy way to draw a circle in C. Such a simple task...

Oh well. Maybe someone more knowledgable than me will explain all these details I've left out or don't know.

[jdratlif]

i'd perfer WxWidgets over gtk.

and SDL isn't really at the same level of functionality as DX. I think all the input improvements made with the switch to DX8 would be lost.

they intend it to be modular, so a native Win32 API GUI wouldn't be out of the question.

What exactly are you doing with your controller that SDL cannot handle? More importantly, you are talking about the difference b/w DX 7 and DX 8, which has nothing to do with SDL. Why do you assume it would be worse?

And the point is not to be modular, it's to stop maintaining 3 ports. This is exactly why a native GUI would be out of the question.

The worst thing about FCEU is how Xod created a nice Windows GUI and hasn't made anything for Linux. This is one of the things I love about ZSNES. The GUI is nice, and it works the same in Linux and Windows. Snes9x has a horrible Windows GUI, but the Mac GUI is sweet.

I think focusing one a single, uniform, platform independent base is a great idea.

I've never used wxWidgets, but I've heard good things. How portable is it?

[Noxious Ninja]

What exactly do you mean when you say 'windowing system'?

[grinvader]

What exactly do you mean when you say 'windowing system'?

X ?

[funkyass]

What exactly are you doing with your controller that SDL cannot handle? More importantly, you are talking about the difference b/w DX 7 and DX 8, which has nothing to do with SDL. Why do you assume it would be worse?

SDL on windows is a flimsy wrapper to DX anyways, and linked to only use DX5. So you'd lose a fair bit of functionality in audio and input. So its more likely SDL won't be used on windows anyways.

And the point is not to be modular, it's to stop maintaining 3 ports. This is exactly why a native GUI would be out of the question.

you have no clue what modular means, do you? Think winamp. its a software design concept, portitioning bits of the design into easily replacable units.

[LDAWG]

If this was a perfect world (where we all used Linux), I say, "Go SDL for sure!"
...but DX5 only? yikes...
I would be sad, when I had to play ZSNES at work, on all those win32 PCs.

Welp, I better go tell the President of the Company, to start switching all of us over to Linux!
Now... which distro should I advise him on?

[jdratlif]

What exactly do you mean when you say 'windowing system'?

X ?

I'm referring to an API for creating Windows as frames for applications. There is a Windows native API, and then there are several wrappers that use Windows somewhere in there, but are portable and wrap other windowing systems APIs for displaying windows.

X is an API for creating windows. But you cannot write something in X and have it compile under Windows. But you can write to SDL, and have it compile on both.

Glut was another such windowing system (maybe I could have been more term clear -- windowing API maybe?)

Native apps are not portable. Take a look at the zsnes source code. Note the zloader.c programs. There's one for the Windows port, one for the DOS port, and one for the SDL (Linux) port.

But (possibly aside from DOS -- I've never heard of SDL in DOS, but who hears much about DOS these days?), you could run the SDL port in Windows if there were some changes in the base assumptions (like SDL = Linux = BSD sockets for Netplay for example).

[jdratlif]

What exactly are you doing with your controller that SDL cannot handle? More importantly, you are talking about the difference b/w DX 7 and DX 8, which has nothing to do with SDL. Why do you assume it would be worse?

SDL on windows is a flimsy wrapper to DX anyways, and linked to only use DX5. So you'd lose a fair bit of functionality in audio and input. So its more likely SDL won't be used on windows anyways.

I don't really know about how SDL is underpinned. Is it DX5? That sounds bad.

I have never experienced a DX5 app though.

Also, I don't know what the problems were from the DX7 to DX8 input switch. I only know there were problems.

What I do know is this. SDL is designed to be portable and the Linux SDL version of ZSNES has never given me any problems. This of course does lend any credence to the theory that SDL on Windows would be good, but I would at least think it comparable.

I only wish I had an SDL app on Windows that I used enough to have some firsthand experience.

And the point is not to be modular, it's to stop maintaining 3 ports. This is exactly why a native GUI would be out of the question.

you have no clue what modular means, do you? Think winamp. its a software design concept, portitioning bits of the design into easily replacable units.

I missed part of the IRC transcript. But here is what I gleaned from it (after a reread).

Modularize the code. What this means to me: stop making everything dependent on everything else. Have you looked at the GUI code? It would be very hard to replace it right now, but it's extremely difficult to maintain as is. So, modularization does not necessarily imply redundant piece development ala Winamp via skins or plugins. Whether or not somone else creates these things at a later date is up for speculation. I don't mean to suggest that because the ZSNES doesn't do it that it couldn't be done once modularization is complete.

The greater purpose (seems to me) is to remove the Windows and DOS ports and focus on a single maintainable unit. This would suggest a uniform GUI in a windowing system independent API (such as GTK (if indeed it is a windowing system API and not just a widget API -- not sure on that), glut (god forbid), SDL, or whatever).

I could be wrong. But I don't think the developers have any interest in writing a windows native GUI, and an alternative platform GUI. That is what I gleaned from Nach's posts and the IRC transcript.

I don't know enough about the underpinnings of SDL to know if that would seriously degrade Windows performance or not. But why they would make so much talk about SDL (or gtk) and Linux and removing the win32/DOS code if they intend to put a new one in its place I don't know.

[Kagerato]

You cannot code OpenGL without an underlying window system. OpenGL is completely platform independent. It only lets you draw things on the screen. This means you cannot write an OpenGL program unless you use a windowing toolkit as well.

As far as I know, this is accurate. I've looked for some program that uses OpenGL under DOS, and found nothing. If OpenGL does not require a windowing environment, then it should be capable of being used under DOS. Granted, a fairly recent puffed up DOS which is 32-bit, but still the disk operating system.

The fact that you can choose to not use OpenGL with SDL does not mean SDL is slow.

Anyone claiming SDL is slow hasn't seen some of the programs that use it.

To my knowledge, SDL accesses the 3D hardware through OpenGL. Therefore, there seems to be a link that you're omitting here.

However, that brings up another issue. SDL is a platform independent window toolkit. It has nothing to do with standardized GUI controls. This means you get a window, and control of the IO devices with SDL, but it won't make you a menu or a toolbar or a button, etc.

I have never heard of any windowing toolkit in SDL, the simple directmedia layer. SDL is designed to be a multimedia library. It provides an abstraction to the hardware so that the programmer can write their demo/game/fancy screensaver without caring about the particular details of the machine. SDL and DirectX are equivalent technologies. SDL and any windowing system makes no sense as an analogy.

This is the only reason DirectX is nice. It's a giant repository of everything you would ever need. Windowing toolkit, graphic primitives (ala OpenGL -- is that the right term 'ala'? I don't think it uses OpenGL. I think vendors support two standards because Microsoft backs one and everyone else backs the other, but I could be wrong. Been a long time since I took gfx, and we only did OpenGL), and a GUI toolkit using the windows standard interface.

DirectX has little, if anything, to do with GDI; they're separate and distinct. It is possible for one to access the other, but because the libraries they use are independent and do not have to be used in conjunction it is unfair to consider them connected.

There is not much at all that DirectX [a set of multimedia libraries] provides which SDL does not.

GTK, I believe, is a combination GUI toolkit and windowing system. This would give it a slight advantage over SDL from a developer standpoint, assuming you cannot using GTK widgets from an SDL window system. I don't know all the specifics. I've only barely begun to examine SDL and GTK (someday I'ld like to write programs that use GUIs that aren't Java).

GTK is a GUI toolkit, not a windowing system.

Some time ago, I was teaching myself C++. I was rewriting into Java lessons in C++. But I couldn't quite get the graphics all figured out. There just wasn't any easy way to draw a circle in C. Such a simple task...

The standard C libraries are small, and were built to be that way. Java is a newer and more bloated language that intentionally contains a greater number of standard abstraction libraries.

I'm referring to an API for creating Windows as frames for applications. There is a Windows native API, and then there are several wrappers that use Windows somewhere in there, but are portable and wrap other windowing systems APIs for displaying windows.

Whether an graphical user interface toolkit calls Win32 or not is irrelevant to its portability, actually. You seem to be implying, if not outright stating, something quite different.

wxWidgets is just one implementation of a cross-platform toolkit whose programs natively attach to the GUI subsystem on the computer it is compiled for. The standard widget toolkit (SWT), used primarily in conjunction with the Eclipse project, is another. There are quite a number of others.

X is an API for creating windows. But you cannot write something in X and have it compile under Windows. But you can write to SDL, and have it compile on both.

X11 is a standard for establishing the basic communication of the windowing environment. X11 does not create any windows. The window manager provides all the functionality of creating and maintaining windows. Examples of window managers: fvwm, twm, enlightenment, blackbox, metacity. Suites like gnome and kde also contain a window manager, though it is only part of their immense number of programs and packages.

There is at least one implementation of X11 that runs under Microsoft Windows. So you'd be wrong to say that a program written for X does not compile and run in Windows as well.

There is also, of course, cross-compilation (usually unnecessary). Ever hear of Cygwin? With that in mind, your statement needs much refining under many interpretations.

Native apps are not portable. Take a look at the zsnes source code. Note the zloader.c programs. There's one for the Windows port, one for the DOS port, and one for the SDL (Linux) port.

The distinction between "native" and "platform independent" applications has lost a great deal of its worth, if it ever had any. Unix-like systems have been promoting cross-platform capability through source compilation for decades now. The code generated by compiling a cross-platform program on a different system than what it was designed on is perfectly native; it is physical instructions for the corresponding processor instruction set of the system. There really isn't much else to denote whether a program is native or not.

[Aerdan]

Sure, let's compare Windows to PC Hardware.

Ehm... wxwindows works on near every platform and OS, despite the name (confusions like this one are the main reason because of the name change to wxwidgets)...

Windows does not work on SPARC workstations, Macs, routers, 486's, 486's, 286's, PS2s, X-Boxes, DCs, Gamecubes, Dreamcasts, SNES's, GBA's, NES's, GBC's, or GB's. Try again.

[Thalon]

May I humble suggest to wait after the next release before abandoning dos port forever?
I'm still using it (and honestly I think that I could easily use the win port without problem the day the team will decide to give a glorious death to that outdated piece of code), and I would gladly see a last and stable (almost stable, ok, better not to exaggerate when speaking of emulation) official release with almost everything (only spc7110 and satellaview are missing at this time, right? A "base" snes unit is almost perfectly emulated, except some timing problems and white noises in games made by Squaresoft) emulated...

[Noxious Ninja]

Glut was another such windowing system (maybe I could have been more term clear -- windowing API maybe?)

Basically, you mean something to create a rendering context and recieve input.

As far as I know, this is accurate. I've looked for some program that uses OpenGL under DOS, and found nothing. If OpenGL does not require a windowing environment, then it should be capable of being used under DOS. Granted, a fairly recent puffed up DOS which is 32-bit, but still the disk operating system.

All it would really require is DOS drivers.

Windows does not work on SPARC workstations, Macs, routers, 486's, 486's, 286's, PS2s, X-Boxes, DCs, Gamecubes, Dreamcasts, SNES's, GBA's, NES's, GBC's, or GB's. Try again.

wxWidgets (nee wxWindows) is a cross-platform GUI toolkit and has nothing to do with Microsoft Windows save that it runs on MS Windows.

[jdratlif]

You cannot code OpenGL without an underlying window system. OpenGL is completely platform independent. It only lets you draw things on the screen. This means you cannot write an OpenGL program unless you use a windowing toolkit as well.

As far as I know, this is accurate. I've looked for some program that uses OpenGL under DOS, and found nothing. If OpenGL does not require a windowing environment, then it should be capable of being used under DOS. Granted, a fairly recent puffed up DOS which is 32-bit, but still the disk operating system.

I misspoke. I shouldn't have said windowing toolkit as much as some way of addressing the screen. You must provide the "screen" that OpenGL draws on. In general, this would be a window system API such as X or Win32. I see no real reason why OpenGL couldn't run in DOS, but I have never seen anything related to this.

The fact that you can choose to not use OpenGL with SDL does not mean SDL is slow.

Anyone claiming SDL is slow hasn't seen some of the programs that use it.

To my knowledge, SDL accesses the 3D hardware through OpenGL. Therefore, there seems to be a link that you're omitting here.

Accelerated hardware display is capable through OpenGL. But you can draw on a window in SDL without OpenGL. Read the SDL docs if you don't believe me. You specifically have to enable OpenGL to access the OpenGL system. But you are not required to enable it. So, SDL could be slow, provided you are not using accelerated hardware support via OpenGL or some such similar method.

However, that brings up another issue. SDL is a platform independent window toolkit. It has nothing to do with standardized GUI controls. This means you get a window, and control of the IO devices with SDL, but it won't make you a menu or a toolbar or a button, etc.

I have never heard of any windowing toolkit in SDL, the simple directmedia layer. SDL is designed to be a multimedia library. It provides an abstraction to the hardware so that the programmer can write their demo/game/fancy screensaver without caring about the particular details of the machine. SDL and DirectX are equivalent technologies. SDL and any windowing system makes no sense as an analogy.

One part of being a multimedia library is video. Video cannot exist without some screen to draw on. One of the things SDL provides is a screen. Win32 native APIs are also screens, as are the X11 windowing system.

This is the only reason DirectX is nice. It's a giant repository of everything you would ever need. Windowing toolkit, graphic primitives (ala OpenGL -- is that the right term 'ala'? I don't think it uses OpenGL. I think vendors support two standards because Microsoft backs one and everyone else backs the other, but I could be wrong. Been a long time since I took gfx, and we only did OpenGL), and a GUI toolkit using the windows standard interface.

DirectX has little, if anything, to do with GDI; they're separate and distinct. It is possible for one to access the other, but because the libraries they use are independent and do not have to be used in conjunction it is unfair to consider them connected.

There is not much at all that DirectX [a set of multimedia libraries] provides which SDL does not.

I did not mean to imply that DX was the windowing system + the widgets + the mm system. Only that if you take advantage of DX (native to win32), you are likely to do the same with regard to widgets and the windowing system.

GTK, I believe, is a combination GUI toolkit and windowing system. This would give it a slight advantage over SDL from a developer standpoint, assuming you cannot using GTK widgets from an SDL window system. I don't know all the specifics. I've only barely begun to examine SDL and GTK (someday I'ld like to write programs that use GUIs that aren't Java).

GTK is a GUI toolkit, not a windowing system.

Some time ago, I was teaching myself C++. I was rewriting into Java lessons in C++. But I couldn't quite get the graphics all figured out. There just wasn't any easy way to draw a circle in C. Such a simple task...

The standard C libraries are small, and were built to be that way. Java is a newer and more bloated language that intentionally contains a greater number of standard abstraction libraries.

I wasn't very specific. To elaborate, I was referring to drawing a circle with OpenGL in an SDL application window.

I'm referring to an API for creating Windows as frames for applications. There is a Windows native API, and then there are several wrappers that use Windows somewhere in there, but are portable and wrap other windowing systems APIs for displaying windows.

Whether an graphical user interface toolkit calls Win32 or not is irrelevant to its portability, actually. You seem to be implying, if not outright stating, something quite different.

wxWidgets is just one implementation of a cross-platform toolkit whose programs natively attach to the GUI subsystem on the computer it is compiled for. The standard widget toolkit (SWT), used primarily in conjunction with the Eclipse project, is another. There are quite a number of others.

That's not what I said at all. I am talking about the application frame. What contains the application. Not the GUI, not the widgets, not what's drawn inside the frame. Just the frame. This is window system dependent. SDL wraps the Win32 interface on Windows, and the X11 interface on X systems.

Glut is another wrapper for Win32 or X11, but wihout the mm enhancements of SDL. DirectX is just the mm system. I have no specific information about wxWidgets or SWT.

From what I have seen on the GTK+ website, gtk is a windowing API (wrapper to native systems such as X) and a widget toolkit. I am basing this on the fact that they have a hello world program that creates a window using GTK. That window is the frame.

I will grant my terminology was not the best. When I say windowing system, I am talking about an API (native or wrapper, doesn't matter) for creating windows that are frames (containers) for applications. Using this definition, Win32 is a windowing system, as is X11, Glut, SDL, and GTK. I do not know enought about wxWidgets or SWT to talk about them.

X is an API for creating windows. But you cannot write something in X and have it compile under Windows. But you can write to SDL, and have it compile on both.

X11 is a standard for establishing the basic communication of the windowing environment. X11 does not create any windows. The window manager provides all the functionality of creating and maintaining windows. Examples of window managers: fvwm, twm, enlightenment, blackbox, metacity. Suites like gnome and kde also contain a window manager, though it is only part of their immense number of programs and packages.

A window manager does just what the name implies, it MANAGES windows. It does not create them. If it did, every X application would have to be tailored for every window manager, unless by some astonishing coincidence they all decided to use an identical API. It provides nice little decorations and placement tools, but does not create windows. Xlib does that.

You have obviously never seen an old X11 application.

I wish I still had my first edition RedHat Linux unleashed book. It had example programs written in Xlib. They were horrible. But it's no worse than writing a Win32 application without MFC or the windows widgets.

There is at least one implementation of X11 that runs under Microsoft Windows. So you'd be wrong to say that a program written for X does not compile and run in Windows as well.

I think my meaning was obvious. You can't run X programs without an X Server. If you don't have an X Server, you don't have X applications. Native X11 applications will not run under Windows. You are describing them running under X Windows which happens to be running in Windows.

This seems equivalent to saying I'm running Nesticle in Windows XP if I run Windows 98 under vmware and run Nesticle in the virtual machine. Nesticle does not run in Windows XP. Just because Windows XP happens to running underneath vmware underneath Windows 98 does not imply that Nesticle runs under Windows XP.

There is also, of course, cross-compilation (usually unnecessary). Ever hear of Cygwin? With that in mind, your statement needs much refining under many interpretations.

Cygwin is an emulation layer. It is not a cross-compiler. You might cross-compile on cygwin, but this is not the purpose of cygwin. The purpose of cygwin is to provide a wrapper for POSIX system calls (and related bric-a-brac) in Windows. It is an emulator in much the same sense that zsnes is an emulator.

Cross-compilation compiles an application for another system on your system. Like compiling calculator programs on Windows, or compiling NSRT DOS on Linux.

Native apps are not portable. Take a look at the zsnes source code. Note the zloader.c programs. There's one for the Windows port, one for the DOS port, and one for the SDL (Linux) port.

The distinction between "native" and "platform independent" applications has lost a great deal of its worth, if it ever had any. Unix-like systems have been promoting cross-platform capability through source compilation for decades now. The code generated by compiling a cross-platform program on a different system than what it was designed on is perfectly native; it is physical instructions for the corresponding processor instruction set of the system. There really isn't much else to denote whether a program is native or not.

I don't think you've read or understood what I said at all.

I'm talking about native windowing systems.

SDL wraps Win32 in the windows port, and X11 in the Linux port. So an SDL app will run in both, if you write to SDL.

But the same app w/o SDL has two versions, the X11 window API version (or whatever wrapper you use above that, Xt, gtk, motif, etc) and the Win32 window API version.


C programs for unix are rarely designed for an operating system in the way a windows program is designed for Windows.


Unix portability is also a myth. It may be largely similar, but there are big differences. Why do you think things like Imakefiles and configure scripts exist?

You also seem to think that native means processor. I never mentioned processor and nothing I said has anything to do with that.

[jdratlif]

Glut was another such windowing system (maybe I could have been more term clear -- windowing API maybe?)

Basically, you mean something to create a rendering context and recieve input.

Yes.

[Ichinisan]

How will SDL effect netplay? I assume that the DOS, Windows, and *nix versions would be inter-compatible.

Will I be required to install an SDL environment, or is the SDL environment attached to a different executable for each OS?