Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (710)
Games in Android Showcase (212)
games submitted by our members
Games in WIP (784)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Autogenerated native stub code  (Read 2196 times)
0 Members and 1 Guest are viewing this topic.
Offline elias

Senior Devvie

« Posted 2004-01-14 17:12:58 »

Hi everyone,

I've grown kinda annoyed having to write and recompile the native code for LWJGL for every platform we support (especially for Cas the lazy bum who doesn't like to get his hands all dirty touching a linux box :-D). And we don't even have readily access to a real Mac at the moment. So a crazy idea of mine was why not simply autocreate the native code? To do that, I think, we need:

1. To create an class mapping C structs to an internal ByteBuffer using reflection something like the way Cas wanted the Structs API extension to java. That way, almost every traditional C function argument can be described by a primitive type, a Buffer object or a Struct (at least that's what I hoped).

2. To redesign all native parts of LWJGL to use SWT style. That is, have all (OS) native calls be simple and easily generated stubs at the native side and let platform specific java classes handle the work done in native code today. This is already done for OpenGL for obvious reasons, but the real platform dependent code needs a lot of work here.

3. For each platform, find out how its dynamic libraries are built and then autocreate each and every native stub from the java declarations. Something like:

push the args
call the function pointer (fetched at some library init point)

4. Now only the jar and openal will have to be distributed along with the game.

Obviously that's a lot of work, and quite a few details are missing (like how to handle structs within structs? or C arrays that lack explicit length information). The work isn't pressing, as it won't introduce any public API changes, but I wonder if anybody had ever tried something like this before? I know almost nothing about dynamic library layouts and only a little (win32/SPARC) assembler, but that doesn't scare me yet.

- elias

Offline abies

Senior Devvie

« Reply #1 - Posted 2004-01-14 17:49:25 »

Have you considered using gluegen from Jogl ? I think it does exactly what you want. On the other hand, if LWJGL would start to use gluegen, it might be easier to just port rest of it on top of jogl Smiley

Artur Biesiadowski
Offline elias

Senior Devvie

« Reply #2 - Posted 2004-01-14 18:10:53 »

I'm guessing here, but isn't gluegen "only" generating source code (and even that is from a gl.h file if I'm not mistaken)? I want to go all the way, creating the dll for System.loadLibrary to load.

- elias

Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline abies

Senior Devvie

« Reply #3 - Posted 2004-01-14 18:20:06 »

Yes, it is created also from gl.h, but it is smart enough to handle many non-cryptic headers out there.

What do you mean by 'only source' ? It generates both java and C part, it is enough to run gcc with few parameters to turn all c files into dll.

Artur Biesiadowski
Offline swpalmer

JGO Coder

Exp: 12 years

Where's the Kaboom?

« Reply #4 - Posted 2004-01-15 11:44:34 »

elias is saying he want's to generate the required machine code for the stubs and write out the DLL, .so, etc.  from Java.  Since the calls are so simple this won't need a C compiler.. just something that pushes args and calls a method for whatever OS is supported.
It sounds cool, but I don't know how practical it is.

Offline abies

Senior Devvie

« Reply #5 - Posted 2004-01-15 11:55:49 »

Maybe something like would work ? (it is commercial software, but it should be possible to write it yourself).

Artur Biesiadowski
Offline princec

« JGO Spiffy Duke »

Medals: 892
Projects: 3
Exp: 16 years

Eh? Who? What? ... Me?

« Reply #6 - Posted 2004-01-15 12:35:03 »

The code which xFunction is based on has been publicly available as a JNI example (for x86 at least) for some time now, but it's not quite what we want, although it'll do what we need it to. Trouble is it created millions of objects as the primitive arguments have to be wrapped and that'll never cut it in a performance situation.

What we're looking at here is actually writing a .dll or .so or .dylib out on first run in the correct binary format for the platform.

A tall order, I suspect Sad

Cas Smiley

Pages: [1]
  ignore  |  Print  
You cannot reply to this message, because it is very, very old.

numerical (67 views)
2017-02-21 07:32:16

numerical (68 views)
2017-02-21 07:31:46

theagentd (173 views)
2017-02-18 13:42:33

theagentd (176 views)
2017-02-18 13:35:16

h.pernpeintner (1339 views)
2017-01-24 22:39:11

h.pernpeintner (1327 views)
2017-01-24 22:38:32

Galdo (1888 views)
2017-01-12 13:44:09

Archive (1976 views)
2017-01-02 05:31:41

0AndrewShepherd0 (2515 views)
2016-12-16 03:58:39

0AndrewShepherd0 (2309 views)
2016-12-15 21:50:57
List of Learning Resources
by elect
2016-09-09 09:47:55

List of Learning Resources
by elect
2016-09-08 09:47:20

List of Learning Resources
by elect
2016-09-08 09:46:51

List of Learning Resources
by elect
2016-09-08 09:46:27

List of Learning Resources
by elect
2016-09-08 09:45:41

List of Learning Resources
by elect
2016-09-08 08:39:20

List of Learning Resources
by elect
2016-09-08 08:38:19

Rendering resources
by Roquen
2016-08-08 05:55:21 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!