Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - demetrioussharpe

Pages: 1 ... 8 9 [10] 11 12 ... 14
136
Hardware / Re: OpenGL ddk
« on: 2010.12.15, 17:35:01 »
Thanks for the support guys, it really means a lot!

Does anyone know how to find out if the PM & GPI pipelines have finished drawing everything in their pipeline?

Also, while I'm waiting for netlabs, I've started working on the library's gl rendering pipeline.

137
Hardware / Re: OpenGL ddk
« on: 2010.12.15, 02:42:31 »
Here's an update:

- The codebase at sourceforge is at revision 39.

- Work's in progress to insure that revision 39 is brought up on netlabs.

- I've sent the rsync drop to Adrian as a tarball via email.

- I've reorganized the split between the GL library & the hardware driver; there's no longer a pipeline/raster split, it's all pipeline with the split being lib/hardware; all of this now lives in the pipeline directory, since all drivers that'll be part of the default install will interface to this library. All of this is in my local repo & will be committed once netlabs' repo is up.

- PGL will look for 2 environmental variables; most likely, the names will be GLDEFAULTLIBRARY & GLALTERNATELIBRARY. These variables must be defined in config.sys for usage. GLDEFAULTLIBRARY is the GL library that's part of this DDK & must never be changed. GLALTERNATELIBRARY is the library used if a hardware-specific GL library needs to be loaded. PGL will look for GLALTERNATELIBRARY first & if it's not defined, then PGL will fall back to GLDEFAULTLIBRARY.

- GLDEFAULTLIBRARY will look for 2 environmental variables; most likely, they will be named GLSOFTRENDERER & GLHARDRENDERER. GLSOFTRENDERER will be the software driver that comes with this DDK. It's not a must that it's not changed to point to another software implementation, but I'll ask that it not be changed. If someone comes up with I ask that they contribute to the official codebase. GLHARDRENDERER will point to the hardware driver for the currently installed videocard. As such, it should be changed each time the hardware changes. I am considering doing a massive hardware renderer that uses the correct card-specific routines depending on which card is installed.

I know that some of what I just posted kinda goes without saying, I just wanted to go ahead & write those things down anyway just to make my intent official.

Comments, concerns, gripes, or complaints?

138
Hardware / Re: OpenGL ddk
« on: 2010.12.14, 00:54:23 »
Adding pglGetProcAddress() to the pgl layer. Windows users know it as wglGetProcAddress(). It allows developers to use new functions that are not in the system's default OpenGL installation, but are included either in a chip-specific implementation or as an extension.

139
Hardware / Re: OpenGL ddk
« on: 2010.12.10, 20:38:10 »
Ok, it looks like I've hit a little snag. I'll be the first to admit that I don't know a whole lot about using SVN. I've been able to get along by using TortoiseSVN, since I've been doing the actual development on my Win box. Now, it's time to push the GL/2 repo over from sourceforge to netlabs. I'm at a complete loss at how to accomplish this with all of my version info & commit history intact. Is there anyone keeping track of this forum topic who knows how to accomplish such a thing? Any help would be greatly appreciated!

140
Hardware / Re: OpenGL ddk
« on: 2010.12.08, 00:24:29 »
I've gotta admit, that was quite an overwhelming post! I suppose, I'm used to the actions of 1 person being mostly dismissed at a local level & usually unnoticed at a global level. Such is the way it is in military life. This feels largely new to me. Thanks for your kind words!

141
Hardware / Re: OpenGL ddk
« on: 2010.12.07, 22:37:57 »
Things have been a bit slow for the past few days. It's the holiday season & I'm also winding down my Army career, so it's safe to say that 'Real Life' issues have drained quite a bit of my time. However, here's a small update:

-I've received the info necessary to host this project on Netlabs.
-I've been in the process of updating my commiting tree with code from my sandbox tree.
-When the commiting tree is completely up to date & I've pushed all of the code to sourceforge, I will do a final svn checkout to make sure that my tree is correctly revisioned. That's when I will commit it all to Netlabs & shutdown the sourceforge tree.
-I have successfully built the GLU library as a lib file & included it into the OPENGL.dll project file.
-I have added a GLU function pointer table within PGLContext. This will make it much easier if there comes a time in the future when another GLU library, that's more robust, is created.
-My PGL is almost feature complete with IBM's PGL. Here's the summary of what needs to be finished:

---pglWaitPM() currently has no way to check to make sure that the presentation manager is finished drawing to the viewing area of the window before it returns.
---pgl_internal.[c|h] needs functionality that allows PGL to be able to subclass the window & service specific window messages. It also needs an internal clean up system to register to the Exit system. This will allow PGL to do clean up regardless of whether a program was ended  normally or by force.
---pglUseFont() still needs to be implemented.
---pglUsePMBitmapFont() was depreciated by IBM, so my implementation is well within reason by just returning FALSE. However, I'd like to go ahead & implement it properly for indirect contexts anyway.
---pglMakeCurrent() when a context has been bound to a window for the first time, pglMakeCurrent() needs to attach cleanup routine to program, subclass the window to allow handling of specific window message, get window bounds, & set the viewport to bounds values.


So, I'm a long ways off from where I've started. I've also gained a few ideas for additions to PGL that will not use the standard 'pgl' API format, but will still prove themselves valuable. One such idea is to insert a thin portion of a profiling system within PGL. There would also need to be companion portions within the pipeline & the video driver. This will not only allow me to better understand the choke points through the entire system for a total implementation optimization effort. It will also give developers more insight into which pathways their apps are spending the majority of their time in. Work on this may or may not be started before I start fleshing out the actual pipeline.

I'd like to thank everyone who's given me their support. I will continue make summary reports as time permits.

142
Hardware / Re: OpenGL ddk
« on: 2010.12.07, 22:02:32 »
I'm so excited to hear that this is moving forward, I think OpenGL support for eCS is so important to the OS's health as a viable platform. Thank you!

Thanks for your enthusiasm towards this project. That's the kind of feedback that keeps me going when I think my tank's on 'E' for the night; it's greatly appreciated!

143
USB / Re: OS/2 & eCS USB HID driver incomplete
« on: 2010.11.28, 21:03:05 »
Information about PPD files can be found by following the links starting with http://localhost:631/ and clicking the PPD API link.

localhost???

144
Hardware / Re: OpenGL ddk
« on: 2010.11.27, 21:20:36 »
Learned about a feature of openwatcom that I wasn't aware of before. I'll be reorganizing the tree within the coming days. It'll be easier to insert the GLU library into OPENGL.dll.

145
Hardware / Re: OpenGL ddk
« on: 2010.11.26, 10:13:26 »
Just so it's understood, my OPENGL.dll is not compatible with IBM's pipeline or raster components. Until my pipeline & raster components are uploaded, my OPENGL.dll will be useless. But the code is there for viewing. I'll work on pglUseFont() in the next few days & commit the changes to the repo.

146
Hardware / Re: OpenGL ddk
« on: 2010.11.26, 06:46:28 »
In lieu of netlabs access, I've uploaded the current sources of GL/2 to the sourceforge repo. Access to netlabs is in the works; once it's been granted to me, I will upload the codebase to that repo. What's included in the codebase so far is:

All of the headers in my development tree, courtesy of the openwatcom group.
OPENGL.dll, which resides in the pgl directory.

To compile this code, you will have to place the codebase into a directory, then update the openwatcom project include path to point to the include folder that comes with the gl2 checkout.

147
USB / Re: OS/2 & eCS USB HID driver incomplete
« on: 2010.11.26, 03:22:22 »
Exactly my point. YOU have higher priorities, so it isn't likely to happen, unless somebody else wants to take it on, and most of those who are capable, are already up to their ears in work.

Had I not started the GL/2 work first, I may've jumped right into the joystick problem. Not only do we need a fairly universal joystick driver, we also need a useful framework API to access it. Consider all of that as part of my TODO list. One of my main objectives is to make it easier to bring modern interactive entertainment to OS/2. From my end, this includes OpenGL, OpenAL, joysticks, an input framework for accessing joysticks, & possibly the OSS sound drivers & framework. Some of those are actually easier to do than others, so I may arrange my TODO list by order of difficulty level.

Quote
It will if they can't use a modern browser (exists) with JAVA support, and probably FLASH. Hopefully, that stuff is not too far off. One other thing that *might* cause a problem, would be a new, unproven, kernel. Corporations, and governments, are somewhat skitish about things like that, and it is one of the reasons why many of them have not moved to Linux. Even more work to do...

Unfortunately, I'm a bit lower on the development stack. I stay at the system level. Others will have to take up the mantle of apps porting & development. However, should I produce a viable kernel ready for insertion, can I count on you to give it a shot? A very important part of the development cycle is testing & as you said earlier, corporations will not take to a new kernel so quickly. Luckily, the kernel that I'd like to modify has had tons of testing & has proven itself over the years. If that sounds fair, stay tuned, more to follow.


Quote
That is true. The problem is that few have either the interest, or the time, to try.

I'm doing what I can to lighten the load. Hopefully, I'll be able to produce enough contributions at a fast enough pace to effectively lighten the load a bit.

Quote
That would be great. I have done some programing, but I find that i am not able to concentrate enough to do it successfully. I spend a LOT more time reading the docs, and experimenting to get it to work, than I do actually accomplishing anything. So, I have decided to stick with REXX, and I am learning how to use DrDialog. It still takes ages to accomplish anything. I also do a lot of resting for the PMMail project (not enough to prevent users from finding problems, but I try). I also do some of the support for PMMail.

Ok, well, I'm sure that you'll come in handy as new development roll out.

Quote
Great idea. Where do we find the guy with the music? I suppose we can get along without it though.

Someone always has music. Hopefully, we won't end up in a situation where we have to face the music on OS/2's viability. I hope to make sure that OS/2 continues to sing sweet music & not a swan song.

Quote
Ears aren't very important, if you have no head to hang them on.

If all works out according to plan, we'll have new ears & a new head; both of which I consider equally important. I'm focused on the total body health of OS/2.

Quote
Don't get me wrong, I believe every word that you write, but I am also a realist, and I know that we can't do it all. At the moment, OS/2 is in heavy duty survival mode, and there are not enough people to go around. If one must cut off the ears to ensure the survival of the patient, one must do that. New ears can be added later, once the recovery is made. Of course, if you want a break from your other projects, a joystick driver might be something that somebody, somewhere, might use.

You & I are not much different in our beliefs. Our main differences stem from how we think that our general goals can be achieved. Hopefully, I can help get OS/2 off of life support & into outpatient recovery. You're absolutely correct, there isn't enough people to go around. Which means that I will have to work much harder; not only to become a more visible, contributing part of the community, but also to become a conduit to channel more resources towards OS/2. I seem to get more done when I multitask my development goals. Perhaps I will push the joystick driver into the current development queue.

148
USB / Re: OS/2 & eCS USB HID driver incomplete
« on: 2010.11.25, 21:18:24 »
Well, get at it. It seems that you know how to do these things. I don't, and most users don't. As I said before, there are not enough programers to go around, and there are still only 24 hours in a day. If the OS can't even print, we will lose the corporate world, and they are the ones who are keeping OS/2 alive, at the moment.

My hands are a bit full at the moment with GL/2 & a few other things that I'm not ready to announce yet. As for the corporate world, that's all well & good for now, but eventually, that well is going to run dry. The basis of what I'm saying is that we have to take the future of OS/2 into our own hands. The corporate world is only going to keep OS/2 around as long as there's something in it for them. What do you supposed is going to happen when they can't use OS/2 anymore after one of their hardware upgrades? Not all of my work is based on gaming. Some of my work is more serious. But, like you said, there's only 24hrs a day & I'm a full time soldier. There's only so much that I can do.

Quote
They aren't going to stay with it if it doesn't have those things. Joysticks are usable with games, There is no way that enough games will ever get ported to OS/2 to make a joystick really useful. Anybody who wants to play games is going to use windows. That is the one thing that windows is good for, and that seems to be where the most development money goes. We can never hope to even scratch the surface on that front.

Yes, joysticks are good for games. But there're also good for other things. Consider the other areas that it would be great to get OS/2, eCS, or a future version to get integrated into. Perhaps even robotics, you never know unless you try.

Quote
No, but they surely won't switch to, or stay with, an OS that can't even print.

I use "printing" as one example of many things that OS/2 is lacking.

Well, if OS/2 can't print & if there aren't enough developers to help out in that goal, then perhaps it's time for new developers to be created. The source is out there & the development tools are free. Learning resources are freely available online & can be found anywhere. So, how bad do you want printing support???

Quote
And, it was DirectX that unseated OS/2 too (with more than a little help from IBM). The only way to combat that, is to write our own DirectX, but that would probably result in huge, very expensive, lawsuits, even if it was possible. OS/2 has it's own niche market. and games are not a part of that market. To take even a very small part of that would take a horrendous amount of very hard work, by more people than are available to do it, and you still need to do the basics (printing, JAVA), or it is all for nothing.

We don't have to have DirectX specifically, but we need something. Sure, IBM was holding the hammers & nails for OS/2's coffin, just like everyone else, but that doesn't mean that we have to get into the coffin. Niche markets are fine, but they don't last forever. As far as the hard work, all it takes is people who're willing to meet in the middle. I'll bring the sandwiches, you bring the drinks, & someone else brings the music, now we have a party.

Quote
OS/2 has always been acknowledged as a solid OS that people use to get work done. It never was a gaming system, and I expect that it never will be (Linux isn't either). Sure some games do work with it, but they are not the serious (dare I use that term?) games that are written for windows.Then again, if Odin (or one of it's like) could be expanded to cover all of the required parts, it may actually be possible to run some of the games, and then the joystick support might be useful. Odin seems to be close to a dead end (to few interested developers), so I don't expect that to happen. Not only is it unlikely to happen, but anyone who wastes their time trying to make it happen, takes away one more programer that is vitally needed to make things like printers work.

The OS graveyard is full of solid OS's, so being solid doesn't mean a whole lot. Afterall, look at the situation that OS/2 is in now. We can't afford to lay blame & point fingers, we also don't have the time. Even if Odin was usable, we'd still need a joystick API to hook it into. As for one more programmer being taken away, take personal responsibility for adding one more programmer.

Quote
It's all a matter of priorities. Make the fluff work, or make the basics work. Take your pick. Without the basics, the fluff doesn't matter.

The thing about most pieces of fluff is that it's usually simple & only has to be done once, then it's done. As for priorities, my priority is for it ALL to work. There's no picking & choosing. Just because you can live without your ears, doesn't mean that your ears are not important.

Quote
BTW, by "joystick" I assume you really mean one of those game controllers, with 15 buttons, and a couple of sticks. I am not even sure if an old style joystick is still available, and I am even less sure what it would be good for.

These days, we don't have to worry about the old-school joysticks. Most modern devices will be connected by USB & will have way more functionality than their predecessors.

149
Hi,

well I had bought a bunch of OS/2 development books some months ago... and it included such dealing with GPI/PM programming that I actually am unable to use since I don't "speak" C (+,++,#,...). However I'm afraid the shipping cost to the US (from Germany) will most likely make it unreasonable to send them over... let me know if you think it's worth it once you have your shelves filled with Rob's stuff. Perhaps I have some of those you'll be lacking... of course you'll get them for free if you cover the shipping. Sigh. ;)

Cheers,
Thomas

I guess there must be tons of OS/2 book everywhere except the US.

150
USB / Re: OS/2 & eCS USB HID driver incomplete
« on: 2010.11.25, 11:55:00 »
Hi,

There also used to be a Warpstock presentation by Markus Montkowski, which described certain concepts of HID operation on OS/2 by a sample joystick driver. Also no idea if this information is still available. Markus quit doing OS/2 stuff a long time ago...

Was that perhaps the Diepenbeek (2001 IIRC) Warpstock Europe?
In this case the slides (if any) should be availabkle somewhere... let me see if I can dig them out from a handout CD or some web archive once I'm back home... will post here if I find something. Cheers,

Thomas

Thanks!

Pages: 1 ... 8 9 [10] 11 12 ... 14