Create an account


Thread Rating:
  • 3 Vote(s) - 2.33 Average
  • 1
  • 2
  • 3
  • 4
  • 5
[SUGGESTION] Porting to XreaL

#26
QuakeC -> Python.. no thanks, python is far to slow.
Reply

#27
but we could test it

Quote:Python game logic can be generated by an included QuakeC -> Python translator.

or we could use an older build and modify it (if quakeC existed in this build)
MY NOOB STATS:
[Image: 788.png]
Reply

#28
Let's re-write the game in assembly! lol Think I'll do that after I finish downloading the internet...
ECKZBAWKZ HUGE LIST OF ACHIEVEMENTS GOES HERE....


Oh wait.
Reply

#29
If the game were written in assembly, it would be insanely small and insanely fast!
Reply

#30
Done! This is a small part of sv_main.c "rewritten" (ie. gcc -S) in ASM:

Code:
...
.L1058:
    movq    prog(%rip), %rax
    movl    svs(%rip), %edx
    movl    %edx, 375356(%rax)
    movq    prog(%rip), %rax
    movl    $1168, 375384(%rax)
    movq    prog(%rip), %rax
    movq    $.LC405, 376232(%rax)
    movq    prog(%rip), %rax
    movq    vm_sv_extensions(%rip), %rdx
    movq    %rdx, 376248(%rax)
    movq    prog(%rip), %rax
    movl    $1, 376256(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_BeginIncreaseEdicts, 376296(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_EndIncreaseEdicts, 376304(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_InitEdict, 376312(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_FreeEdict, 376320(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_CountEdicts, 376328(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_LoadEdict, 376336(%rax)
    movq    prog(%rip), %rax
    movq    $VM_SV_Cmd_Init, 376344(%rax)
    movq    prog(%rip), %rax
    movq    $VM_SV_Cmd_Reset, 376352(%rax)
    movq    prog(%rip), %rax
    movq    $Host_Error, 376360(%rax)
    movq    prog(%rip), %rax
    movq    $SVVM_ExecuteProgram, 376368(%rax)
    movq    sv_progs+16(%rip), %rax
    movq    $0, (%rsp)
    movl    $0, %r9d
    movl    $reqfields, %r8d
    movl    $70, %ecx
    movl    $0, %edx
    movl    $0, %esi
    movq    %rax, %rdi
    call    PRVM_LoadProgs
    movq    prog(%rip), %rax
    movl    $19, 375432(%rax)
    movq    prog(%rip), %rax
    movl    $60, 375500(%rax)
    movq    prog(%rip), %rax
    movl    $28, 375504(%rax)
    movq    prog(%rip), %rax
    movl    $30, 375620(%rax)
    movq    prog(%rip), %rax
    movl    $47, 375648(%rax)
    movq    prog(%rip), %rax
    movl    $85, 375656(%rax)
    movq    prog(%rip), %rax
    movl    $46, 375704(%rax)
    movq    prog(%rip), %rax
    movl    $44, 375784(%rax)
    movq    prog(%rip), %rax
    movl    $86, 375796(%rax)
    movq    prog(%rip), %rax
    movl    $28, 375904(%rax)
    movq    prog(%rip), %rax
    movl    $31, 375908(%rax)
    movq    prog(%rip), %rax
    movl    $59, 375912(%rax)
    movq    prog(%rip), %rax
    movl    $65, 375916(%rax)
    movq    prog(%rip), %rax
    movl    $62, 375920(%rax)
    movq    prog(%rip), %rax
    movl    $68, 375936(%rax)
    movq    prog(%rip), %rax
    movl    $69, 375940(%rax)
    movq    prog(%rip), %rax
    movl    $70, 375944(%rax)
    movq    prog(%rip), %rax
    movl    $80, 375948(%rax)
    movq    prog(%rip), %rax
    movl    $79, 375952(%rax)
    movq    prog(%rip), %rax
    movl    $71, 375956(%rax)
    movq    prog(%rip), %rax
    movl    $74, 375960(%rax)
    movq    prog(%rip), %rax
    movl    $77, 375964(%rax)
    movq    prog(%rip), %rax
    movl    $78, 375968(%rax)
    movq    prog(%rip), %rax
    movq    prog(%rip), %rdx
    movl    376240(%rdx), %edx
    orl    $1, %edx
    movl    %edx, 376240(%rax)
    call    VM_CustomStats_Clear
    movq    $0, prog(%rip)
    call    SV_Prepare_CSQC
    addq    $24, %rsp
    popq    %rbx
    leave
    ret
    .cfi_endproc
.LFE40:
    .size    SV_VM_Setup, .-SV_VM_Setup
.globl SV_VM_Begin
    .type    SV_VM_Begin, @function
SV_VM_Begin:
...

So, any volunteers to maintain it? Smile
[Image: vN3NkMA]
(Idea stolen from Mr. Bougo. Hehehehe)
Reply

#31
LOL! Looks like someone was bored. Or maybe he's so desperate to get the game to run on his rig that he's going to re-write so it does. lol Pentium II and ATI Rage for life!
ECKZBAWKZ HUGE LIST OF ACHIEVEMENTS GOES HERE....


Oh wait.
Reply

#32
Python seems like an option for me. But can it be compiled to run as fast as QuakeC? (hey! that rhymed!)

If we are close to python: Blender Game Engine Big Grin

Supports SDL sound, Python, GLSL... IIRC even shaders or screen filters can be written in there.

Btw.. could there be a way to export GLSL shaders made in Blender to use them in DP? Because Blender can do some ultra-cool stuff with stacking textures. I was playing with it and it's possible to create pseudo-randomly non-linear looking materials.
(12-03-2010, 01:20 AM)clanclanclan Wrote: Done! This is a small part of sv_main.c "rewritten" (ie. gcc -S) in ASM:

Code:
...
.L1058:
    movq    prog(%rip), %rax
    movl    svs(%rip), %edx
    movl    %edx, 375356(%rax)
    movq    prog(%rip), %rax
    movl    $1168, 375384(%rax)
    movq    prog(%rip), %rax
    movq    $.LC405, 376232(%rax)
    movq    prog(%rip), %rax
    movq    vm_sv_extensions(%rip), %rdx
    movq    %rdx, 376248(%rax)
    movq    prog(%rip), %rax
    movl    $1, 376256(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_BeginIncreaseEdicts, 376296(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_EndIncreaseEdicts, 376304(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_InitEdict, 376312(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_FreeEdict, 376320(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_CountEdicts, 376328(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_LoadEdict, 376336(%rax)
    movq    prog(%rip), %rax
    movq    $VM_SV_Cmd_Init, 376344(%rax)
    movq    prog(%rip), %rax
    movq    $VM_SV_Cmd_Reset, 376352(%rax)
    movq    prog(%rip), %rax
    movq    $Host_Error, 376360(%rax)
    movq    prog(%rip), %rax
    movq    $SVVM_ExecuteProgram, 376368(%rax)
    movq    sv_progs+16(%rip), %rax
    movq    $0, (%rsp)
    movl    $0, %r9d
    movl    $reqfields, %r8d
    movl    $70, %ecx
    movl    $0, %edx
    movl    $0, %esi
    movq    %rax, %rdi
    call    PRVM_LoadProgs
    movq    prog(%rip), %rax
    movl    $19, 375432(%rax)
    movq    prog(%rip), %rax
    movl    $60, 375500(%rax)
    movq    prog(%rip), %rax
    movl    $28, 375504(%rax)
    movq    prog(%rip), %rax
    movl    $30, 375620(%rax)
    movq    prog(%rip), %rax
    movl    $47, 375648(%rax)
    movq    prog(%rip), %rax
    movl    $85, 375656(%rax)
    movq    prog(%rip), %rax
    movl    $46, 375704(%rax)
    movq    prog(%rip), %rax
    movl    $44, 375784(%rax)
    movq    prog(%rip), %rax
    movl    $86, 375796(%rax)
    movq    prog(%rip), %rax
    movl    $28, 375904(%rax)
    movq    prog(%rip), %rax
    movl    $31, 375908(%rax)
    movq    prog(%rip), %rax
    movl    $59, 375912(%rax)
    movq    prog(%rip), %rax
    movl    $65, 375916(%rax)
    movq    prog(%rip), %rax
    movl    $62, 375920(%rax)
    movq    prog(%rip), %rax
    movl    $68, 375936(%rax)
    movq    prog(%rip), %rax
    movl    $69, 375940(%rax)
    movq    prog(%rip), %rax
    movl    $70, 375944(%rax)
    movq    prog(%rip), %rax
    movl    $80, 375948(%rax)
    movq    prog(%rip), %rax
    movl    $79, 375952(%rax)
    movq    prog(%rip), %rax
    movl    $71, 375956(%rax)
    movq    prog(%rip), %rax
    movl    $74, 375960(%rax)
    movq    prog(%rip), %rax
    movl    $77, 375964(%rax)
    movq    prog(%rip), %rax
    movl    $78, 375968(%rax)
    movq    prog(%rip), %rax
    movq    prog(%rip), %rdx
    movl    376240(%rdx), %edx
    orl    $1, %edx
    movl    %edx, 376240(%rax)
    call    VM_CustomStats_Clear
    movq    $0, prog(%rip)
    call    SV_Prepare_CSQC
    addq    $24, %rsp
    popq    %rbx
    leave
    ret
    .cfi_endproc
.LFE40:
    .size    SV_VM_Setup, .-SV_VM_Setup
.globl SV_VM_Begin
    .type    SV_VM_Begin, @function
SV_VM_Begin:
...

So, any volunteers to maintain it? Smile

Cool Big Grin Let's re-write DP in ASM Big Grin Big Grin It will be 10 times faster!
I'm making Liblast - a FOSS online FPS game made with Godot 4 and a 100% open-source toolchain
Reply

#33
(12-03-2010, 08:00 PM)unfa Wrote: Python seems like an option for me. But can it be compiled to run as fast as QuakeC? (hey! that rhymed!)

If we are close to python: Blender Game Engine Big Grin

Supports SDL sound, Python, GLSL... IIRC even shaders or screen filters can be written in there.

Btw.. could there be a way to export GLSL shaders made in Blender to use them in DP? Because Blender can do some ultra-cool stuff with stacking textures. I was playing with it and it's possible to create pseudo-randomly non-linear looking materials.
(12-03-2010, 01:20 AM)clanclanclan Wrote: Done! This is a small part of sv_main.c "rewritten" (ie. gcc -S) in ASM:

Code:
...
.L1058:
    movq    prog(%rip), %rax
    movl    svs(%rip), %edx
    movl    %edx, 375356(%rax)
    movq    prog(%rip), %rax
    movl    $1168, 375384(%rax)
    movq    prog(%rip), %rax
    movq    $.LC405, 376232(%rax)
    movq    prog(%rip), %rax
    movq    vm_sv_extensions(%rip), %rdx
    movq    %rdx, 376248(%rax)
    movq    prog(%rip), %rax
    movl    $1, 376256(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_BeginIncreaseEdicts, 376296(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_EndIncreaseEdicts, 376304(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_InitEdict, 376312(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_FreeEdict, 376320(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_CountEdicts, 376328(%rax)
    movq    prog(%rip), %rax
    movq    $SV_VM_CB_LoadEdict, 376336(%rax)
    movq    prog(%rip), %rax
    movq    $VM_SV_Cmd_Init, 376344(%rax)
    movq    prog(%rip), %rax
    movq    $VM_SV_Cmd_Reset, 376352(%rax)
    movq    prog(%rip), %rax
    movq    $Host_Error, 376360(%rax)
    movq    prog(%rip), %rax
    movq    $SVVM_ExecuteProgram, 376368(%rax)
    movq    sv_progs+16(%rip), %rax
    movq    $0, (%rsp)
    movl    $0, %r9d
    movl    $reqfields, %r8d
    movl    $70, %ecx
    movl    $0, %edx
    movl    $0, %esi
    movq    %rax, %rdi
    call    PRVM_LoadProgs
    movq    prog(%rip), %rax
    movl    $19, 375432(%rax)
    movq    prog(%rip), %rax
    movl    $60, 375500(%rax)
    movq    prog(%rip), %rax
    movl    $28, 375504(%rax)
    movq    prog(%rip), %rax
    movl    $30, 375620(%rax)
    movq    prog(%rip), %rax
    movl    $47, 375648(%rax)
    movq    prog(%rip), %rax
    movl    $85, 375656(%rax)
    movq    prog(%rip), %rax
    movl    $46, 375704(%rax)
    movq    prog(%rip), %rax
    movl    $44, 375784(%rax)
    movq    prog(%rip), %rax
    movl    $86, 375796(%rax)
    movq    prog(%rip), %rax
    movl    $28, 375904(%rax)
    movq    prog(%rip), %rax
    movl    $31, 375908(%rax)
    movq    prog(%rip), %rax
    movl    $59, 375912(%rax)
    movq    prog(%rip), %rax
    movl    $65, 375916(%rax)
    movq    prog(%rip), %rax
    movl    $62, 375920(%rax)
    movq    prog(%rip), %rax
    movl    $68, 375936(%rax)
    movq    prog(%rip), %rax
    movl    $69, 375940(%rax)
    movq    prog(%rip), %rax
    movl    $70, 375944(%rax)
    movq    prog(%rip), %rax
    movl    $80, 375948(%rax)
    movq    prog(%rip), %rax
    movl    $79, 375952(%rax)
    movq    prog(%rip), %rax
    movl    $71, 375956(%rax)
    movq    prog(%rip), %rax
    movl    $74, 375960(%rax)
    movq    prog(%rip), %rax
    movl    $77, 375964(%rax)
    movq    prog(%rip), %rax
    movl    $78, 375968(%rax)
    movq    prog(%rip), %rax
    movq    prog(%rip), %rdx
    movl    376240(%rdx), %edx
    orl    $1, %edx
    movl    %edx, 376240(%rax)
    call    VM_CustomStats_Clear
    movq    $0, prog(%rip)
    call    SV_Prepare_CSQC
    addq    $24, %rsp
    popq    %rbx
    leave
    ret
    .cfi_endproc
.LFE40:
    .size    SV_VM_Setup, .-SV_VM_Setup
.globl SV_VM_Begin
    .type    SV_VM_Begin, @function
SV_VM_Begin:
...

So, any volunteers to maintain it? Smile

Cool Big Grin Let's re-write DP in ASM Big Grin Big Grin It will be 10 times faster!

Unfortunately if they were to drop everything and start re-writing the engine, you would already be able to grab a cheap computer that can max the game 5 times over on 2048 X 1536 res lol
ECKZBAWKZ HUGE LIST OF ACHIEVEMENTS GOES HERE....


Oh wait.
Reply

#34
Python is a cool language, but not for this purpose. The only language that could fit here is Lua (which was already tested in many games).

Also, changing the engine is not an option. But Xonotic suffers from being based on some very old technologies. We can't have large outdoor maps, which I would love to see. QuakeC itself is a problem too. Developement is pretty much dependant on Div, other than him, very little ppl dared to touch it.
Reply

#35
(12-20-2010, 07:52 AM)atheros Wrote: Python is a cool language, but not for this purpose. The only language that could fit here is Lua (which was already tested in many games).

That's not true. Both Python and Lua are used heavily in games.

From what I understand though, Lua's interpreter is ~3x faster than CPython, however whenever whatever remains of the Unlaiden Swallow project is finally completed, that gap should be closed.

Now Ruby on the other hand just completely sucks. Tongue
(04-01-2010, 11:21 AM)Roanoke Wrote: Yes, beveled edges are more futuristic. Like BSG and their beveled paper.
But only on one edge.
Reply

#36
interesting read wrt to game code languages - http://shootout.alioth.debian.org/
Reply

#37
(12-22-2010, 07:21 PM)tZork Wrote: interesting read wrt to game code languages - http://shootout.alioth.debian.org/

Huh, well according to that python and lua are equally fast (err, slow). Python 3 still needs some work in this department. Ruby is just plain slower.

Of course, as this shows too, all of the interpreted languages are greatly slower. But this still depends on how much of a game is low level engine and how much of it is actual scripted logic, in terms of system resources usage.
(04-01-2010, 11:21 AM)Roanoke Wrote: Yes, beveled edges are more futuristic. Like BSG and their beveled paper.
But only on one edge.
Reply

#38
Yeh, i got quite a few preconceptions of my own slaughtered by that read. Especial wrt to java. The most interesting bit for me was Lua JIT winch could be a real alternative to QuakeC, quite fast, low overhead and like qc is run as a vm. Also no more akward gamecode compiler would be necessary Tongue Now do NOT misunderstand this; im not saying its going to happen or even can happen. If it does, it will be a loooong term project, even if the engine mods necessary turns out to be easy (yeh... right xD) - the porting of all gamecode is anything but.
Reply

#39
Still, the project's open source. Stuff from their engine can be copied into DP, I guess. Like the fog volumes.
(08-10-2012, 02:37 AM)Mr. Bougo Wrote: Cloud is the new Web 2.0. It makes no damn sense to me.
Reply

#40
(12-24-2010, 07:07 AM)tZork Wrote: The most interesting bit for me was Lua JIT winch could be a real alternative to QuakeC, quite fast, low overhead and like qc is run as a vm. Also no more akward gamecode compiler would be necessary Tongue

Python has it's own equivalent, Psyco, but one minor issue with both it and Lua JIT is each is being advanced and maintained by (what looks like) a single developer.

Quote:Now do NOT misunderstand this; im not saying its going to happen or even can happen. If it does, it will be a loooong term project, even if the engine mods necessary turns out to be easy (yeh... right xD) - the porting of all gamecode is anything but.

I do not really care either way; trying to modernize this engine is a loosing battle. In another decade it will probably be abandoned.

I just come in when I hear a "C++ versus Java" or "Python versus Lua" topic, because these are the tools of free/open game development in general.
(04-01-2010, 11:21 AM)Roanoke Wrote: Yes, beveled edges are more futuristic. Like BSG and their beveled paper.
But only on one edge.
Reply

#41
Never heard of Psyco before (in programming terms ; ). It may be true what you say that lua jit and afore mentioned is a single person project. however (and this does matter a good bit) LUA and Phyton as a language have evolved quite a bit just during the last few years. QuakeC have (as a language) have been stagnant for a long time. This is not necessarily a bad thing in itself, as long as the language is flexible enough to overcome. qc is however limited by design, and those design limits will not support progress forever.

Theres is of course also BOCC witch mostly works but do not optimize (as far as i understand it) atm.

As for modernizing DP - I would not say its a lost battle; but id agree that for the moment its a loosing one. The #1 reason is lack of documentation and tools. As far as an engine goes its quite good; proly above average even compared to (toolchains not included!) commercial ones.
Reply

#42
(12-24-2010, 05:25 PM)tZork Wrote: qc is however limited by design, and those design limits will not support progress forever.

Also no one uses it except those who have learned it for just this game or ancient quake 1. Python and Lua have large user communities to pull developers from.

Quote:As for modernizing DP - I would not say its a lost battle; but id agree that for the moment its a loosing one. The #1 reason is lack of documentation and tools.

This is a similarly major issue to development. Not only do almost none of the potential recruits know the language already, but learning it is seemingly horrendous.

I agree though that you folks can't afford to deal with this issue at all right now. For the health of your project you must focus on the next release.

But in a years time it should be known for sure whether or not id tech 4 will be liberated or if zenimax squashed it. At that time you folks should really take a look at this and the xreal engine as possible new homes. It couldn't be too much work to recreate whatever the "core features" are in another quake engine, most of the same stuff is in each one. But you'd be rid of the legacy failed experiment that is QuakeC. (And then your engine maybe wouldn't be so slow as you've said so of darkplaces?)
(04-01-2010, 11:21 AM)Roanoke Wrote: Yes, beveled edges are more futuristic. Like BSG and their beveled paper.
But only on one edge.
Reply

#43
(11-29-2010, 10:58 AM)unfa Wrote: I'a, not a develper, but I suppose it's better to improve DP than port the game to some other Engine. Porting looks like doing EVERYTHING right from the scratch on the different platform. It doeasn't seem to me like a good way to proceed.

I don't know but I suppose that Dark Places could do much much more thank it can now. And right now - it does a lot.
Only things I can think about as missing are:
  • depth of field
  • volumetric lights
  • rigid (and non-rigid) body physics with joints and all that cool stuff,
  • rag doll
  • dynamic CSG (rather useless in our game - would break the fun from knowing the map)
  • heat distortion from explosions and fire
  • decals on players
  • breaking glass & ice
  • realistic body damage
  • volumetric clouds / smoke simulation
  • fluid simulation (water/lava/slime/blood)
  • map-independent day&night cycle
  • map-independent weather effects: rain, storm, snow, iceberg, wind, mist, sand storm etc...
  • support for large open spaces with trees, grass, water etc.

One thing I missed badly in Nexuiz was trees and grass. I like to have some virtual space. A lot of it. I heard that the DP can't take large open spaces, but maybe it could be optimised, some special features should be developed to make such large terrians possible to make. I miss organic maps Smile There are some but not much. The great majority are industral/space/decay sceneries.

Wait more 50-150 years and all these features will be on Xonotic
(I hope that Xonotic will survive after 150 years)
My in-game name is GooshGoosh!
Reply

#44
LOL Necromancy much?
(08-10-2012, 02:37 AM)Mr. Bougo Wrote: Cloud is the new Web 2.0. It makes no damn sense to me.
Reply

#45
Maybe DP could be modified to support additional scripting language, which is more powerful and modern, keeping QuakeC where it is and works fine.

Over years, there would be less code in QuakeC and more in the other language, and finally QuakeC support could be even dropped.

Long-term thing, but could be possible to make DP much more powerful and convenient to use, without making all the game code unusable and making the entire game unusable for years.
I'm making Liblast - a FOSS online FPS game made with Godot 4 and a 100% open-source toolchain
Reply

#46
An even better solution would be to take the best bits from Xonotic and Nexuiz and then use a different game engine. But which engine, it doesn't have to be GPL compatible - look at Warsow - but it would attract more developers.

The game code or logic can be recreated using whatever language the new engine uses, it will take a long time to port the QC. Converting the models, textures and sounds will be much easier by comparison.
Reply

#47
You also have to think about the other developers like modelers and especially mappers. A different engine also means a different map-editor, and that would be a pain for nearly every mapper here, since the GtkRadiant (or NetRadiant) is the best map editor (my opinion) ever.
Reply

#48
I hear Id Tech 4 source is coming soon.
[Image: foxtrotcproggry.jpg]
Reply

#49
Really? Do you have a specific link?
Reply

#50
Fri 05 Aug 2011, 13:35 "GAMES DEVELOPER Id Software has announced it will release the holy grail of source code, the programming guts of its phenomenally successful first person shooter, Doom 3." here

I assume it will be GPL3 with some extra clauses.

(08-24-2011, 04:57 AM)Maddin Wrote: You also have to think about the other developers like modelers and especially mappers. A different engine also means a different map-editor, and that would be a pain for nearly every mapper here, since the GtkRadiant (or NetRadiant) is the best map editor (my opinion) ever.

What map formats does IDTech 4 support? What about textures, sounds and player models? What scripting language (if any) does it use?
Reply



Possibly Related Threads…
Thread Author Replies Views Last Post
  [SUGGESTION] Porting to FTEqw engine? poVoq 60 46,256 09-05-2023, 06:41 PM
Last Post: LegendGuard
  [SUGGESTION] xreal engine? ugluck 3 5,011 06-29-2010, 05:58 PM
Last Post: FruitieX

Forum Jump:


Users browsing this thread:
1 Guest(s)

Forum software by © MyBB original theme © iAndrew 2016, remixed by -z-