Post by: d0wnlab on July 17, 2006, 10:23:00 PM
I have committed to CVS a number of patches that have been supplied to me by members of the scene over the last week or so.
From Guillaume Lamonoca:
480p support! Currently some problems with 780 and 1080, but the groundwork has been done to add those as well.
From Friedgold:
A workaround to the input handling issue that disables interrupts in favor of polling.
A number of other patches as well, see this thread.
Thanks a lot, guys!!
As I said before, with the OpenXDK version from CVS, input works in a stable manner (as far as we have been able to test), so everyone please update and tell us your findings as well.
There is also work being done on finding out why using interrupts for usb handling did not work - if you're interested in helping this effort PM me and I can get you in touch with the related people.
Cheers,
Tom
Post by: elupus on July 22, 2006, 08:18:00 AM
regards
/elupus
Post by: d0wnlab on July 23, 2006, 11:18:00 AM
Post by: elupus on July 24, 2006, 05:08:00 AM
#ifdef _MSC_VER
PANSI_STRING imageFileName = (PANSI_STRING)XeImageFileName;
#else
PANSI_STRING imageFileName = (PANSI_STRING)&XeImageFileName;
#endif
think the global LaunchDataPage had the same issue, ie different indirection from xdk. Since those aren't really supposed to be accessed i have a fealing nobody will feel like changing that thou
Post by: d0wnlab on July 24, 2006, 09:59:00 AM
We're not going to take out the video init because:
- it will break everything that current builds against openxdk
- you can make a rebuild yourself with it removed (if you want I can supply you with the precompiled library)
Let me know if you want me to build a version without it - but really it's pretty simple to do yourself.
Cheers,
Tom
Post by: elupus on July 26, 2006, 05:01:00 AM
Actually we don't build under msvc, it was just that the code was supposed to work compiled both with oxdk and with xdk wich is why those stuff mattered. anyway it's a small program, so the workarounds isn't any big deal. Just a thought for making porting stuff simpler.
Cheers
Post by: d0wnlab on July 26, 2006, 11:17:00 AM
Post by: TMaul on July 30, 2006, 05:14:00 AM
QUOTE
/usr/local/openxdk/lib/libSDL.a(SDL_blit.o):SDL_blit.c:(.text+0x734): undefined
reference to `_SDL_CalculateBlit0'
/usr/local/openxdk/lib/libusb.a(misc.o):misc.c:(.text+0xab): undefined reference
to `_IoInputDword'
reference to `_SDL_CalculateBlit0'
/usr/local/openxdk/lib/libusb.a(misc.o):misc.c:(.text+0xab): undefined reference
to `_IoInputDword'
I've not yet had a look at why this is happening but I assume that something is missing from cvs thats causing linking problems? Or am I just stupid?
Post by: friedgold on July 30, 2006, 09:47:00 AM
QUOTE(mokda @ Jul 28 2006, 01:38 AM) 
Forgive me for asking, but how do i go about applying this patch? Also, is it dependant on prior patches?
I have openxdk 0.7 as downloaded clean from Source Forge. I noticed that every time I would have to go back and change a few things that was causing problems.
I see that the patch is Makefile.am....how do I run/execute this? I'm using Windows XP fyi.
For the moment if you want these changes you'll need to get the latest version from OpenXDK CVS. There's a guide to CVS on the sourceforge site with more info and links to CVS clients. You'll then need to carry out these install steps to configure and install OpenXDK.
The .am files are used by automake to generate the makefiles used in the build process. If you change a .am file you need to rebuild with make distclean followed by the standard install steps (./autogen.sh; ./configure...).
QUOTE
/usr/local/openxdk/lib/libusb.a(misc.o):misc.c:(.text+0xab): undefined reference
to `_IoInputDword'
to `_IoInputDword'
This should easy to fix. Just add a -lopenxdk after -lusb in the linker options in the makefile.
QUOTE
/usr/local/openxdk/lib/libSDL.a(SDL_blit.o):SDL_blit.c:(.text+0x734): undefined
reference to `_SDL_CalculateBlit0'
Hmm, this is a bit more worrying. I'll try checking out a clean copy of OpenXDK and see if I get the same problem.
reference to `_SDL_CalculateBlit0'
Post by: friedgold on July 30, 2006, 11:16:00 AM
QUOTE
Just add a -lopenxdk after -lusb
Sorry, that should be add a -lhal after -lusb.
Anyway I've just checked out and built OpenXDK from CVS and can build Wolf3d with just that one change to the Wolf3d Makefile so I'm not sure what's happening for you. Did you rebuild OpenXDK completely after doing the CVS update (you need to run make distclean and rerun autogen.sh and configure). Might you have any other copies of the SDL libs or SDL header files in your path?
Post by: mokda on July 30, 2006, 03:14:00 PM
QUOTE(friedgold @ Jul 30 2006, 08:54 AM)
Post by: friedgold on July 30, 2006, 04:08:00 PM
QUOTE
I think the error above is probably due to me missing a cygwin package I should have but didn't know to get.
Yep, you need the patch package too (or whatever cygwin package contains patch).QUOTE
Also, I found some errors in the install guide at openxdk.org...
1) Along with gcc, binutils, automake, and autoconf, you will need "make" for cygwin as well.
True, I'll try to update the docs sometime (the Input API stuff infomation is also out of date).1) Along with gcc, binutils, automake, and autoconf, you will need "make" for cygwin as well.
QUOTE
2) the first command for building the packaged source under cygwin should probably be:
cd /usr/local/openxdk
Even though you install OpenXDK to /usr/local/openxdk you would normally download and compile it elsewhere and then run make install to move the files to the correct directory. So I think the guide is correct in this instance.
cd /usr/local/openxdk
Post by: TMaul on July 30, 2006, 05:17:00 PM
QUOTE(friedgold @ Jul 30 2006, 06:23 PM)
Sorry, that should be add a -lhal after -lusb.
Anyway I've just checked out and built OpenXDK from CVS and can build Wolf3d with just that one change to the Wolf3d Makefile so I'm not sure what's happening for you. Did you rebuild OpenXDK completely after doing the CVS update (you need to run make distclean and rerun autogen.sh and configure). Might you have any other copies of the SDL libs or SDL header files in your path?
Thanks, everything is building fine now. I did suspect that it might be something weird going on with the linking. Also, according to my command history I didn't do a make distclean, only make clean, and that seems to have been the cause of the SDL linking problem.
Thanks again!
Post by: Carcharius on July 31, 2006, 12:43:00 AM
QUOTE(TMaul @ Jul 31 2006, 12:24 AM)
Thanks, everything is building fine now. I did suspect that it might be something weird going on with the linking. Also, according to my command history I didn't do a make distclean, only make clean, and that seems to have been the cause of the SDL linking problem.
Thanks again!
Amateur
Post by: mokda on August 01, 2006, 11:49:00 PM
The same code that worked on 0.7 of openxdk now crashes my xbox when i go to execute it (red/green flashing).
My sample code is basically a mix of the DrawPixel and padTest code from the sample section of CVS.
Post by: openxdkman on August 02, 2006, 12:59:00 AM
See post named "OpenXDK little help"
Post by: alg5 on August 08, 2006, 07:01:00 AM
i'm currently trying openXDK, and i would like to synchronize to the VBL in order to avaid graphics tearing and to have constant speed.
is it possible in current openXDK ?
Post by: openxdkman on August 09, 2006, 11:32:00 AM
Post by: openxdkman on August 10, 2006, 02:50:00 AM
Post by: openxdkman on August 10, 2006, 05:06:00 AM
With standard XBOX kernel, normally, theoretically, you are allowed to run only one main thread.
Just plug the interrupt above somewhere in openxdk and export the vbl_counter variable.
(it's possible it will be officially done later by a person that have rights to insert new code in cvs)
Then you can make your sync function :
void WaitForVBlank()
{
static unsigned long old=0;
while(vbl_counter==old) {};//or any other waiting function
old=vbl_counter;
}
But expert game developers are not doing such waiting...
They work on several screen buffers, and let interruption handler switch display to the next buffer to show.
It's often known as triple buffering technic (first buffer is shown, second one is being finished, last one will be drawn soon... and three pointers rotate to points on them)
And if you detect you are in advance, you can dynamically raise the detail level of the scene...
or lower it if you detect you didn't finish in time last one...
Top graphic speed is not achieved with parallelism made with several threads in the CPU. It's achieved with parallelism between one thread in CPU and massive DMA access in order to provide prepared pushbuffers towards the GPU (fastest games don't even go thru directX or very lightly)
http://www.bringyou.to/games/PS2 is a very interesting article (at the bottom of it you have the description of the port of a very fast game from PS2 towards XBOX and it gives very essential clues)
Post by: openxdkman on August 16, 2006, 02:07:00 AM
If you plan to introduce it officially as a clean cvs change, I would recommend to have an installation and uninstallation function added in hal/video.c
User should be able to register a callback (like in audio.c) that will be called by the vbl interrupt dpc.
About vbl_counter that is a nice way to provide programmer a quicky waitvblank function, you can either export it as global variable or let user register in a clean way his own counter (you pass &vbl_counter as parameter and vbl_counter is a global variable of programmer). In other words you allow the dpc to increment user's var instead of calling a callback...
But I think if we add in the list of samples, a sample that shows how to install and register programmers's callback, that should be enough.
In the sample, inside the callback we can put the vbl_counter++ instruction and vbl_counter will be a global variable of the sample. In the main loop of sample we call waitvblank which just tests counter.
Up to you to choose cleanest way to do it in openxdk, and put the remaining dirty stuff in sample.
But we need both.
And if we give up on vbl programmer's callback we will be screwed for the triple buffering technic.
Post by: openxdkman on October 26, 2006, 09:52:00 AM