Author Topic: TremZ: development and discussion  (Read 78962 times)

SPK

  • Posts: 58
  • Turrets: +2/-0
Re: TremZ: development and discussion
« Reply #30 on: September 22, 2011, 12:04:51 am »
Is it possible to avoid change the current granger model??  T_T
It wont be the same anymore without it. It was so cute...

Well, since GT is involved in the project, I can assure you, the new granger will be absolutely adorable. You will want to meet that granger.

Oh, well, I hope so : D

kharnov

  • Spam Killer
  • *
  • Posts: 626
  • Turrets: +47/-791
    • Unvanquished
Re: TremZ: development and discussion
« Reply #31 on: September 22, 2011, 12:11:52 am »
Oh, well, I hope so : D

We're animating the granger to be very jiggly when it walks. People that shoot it will feel very guilty!

StevenM

  • Posts: 292
  • Turrets: +40/-33
Re: TremZ: development and discussion
« Reply #32 on: September 22, 2011, 12:20:40 am »
Steam is a pretty good marketing strat. As you can see these forums and trem itself are dead. good shit. Hopefully you guys are great success!

CreatureofHell

  • Posts: 2422
  • Turrets: +430/-126
    • Tremtopia
Re: TremZ: development and discussion
« Reply #33 on: September 22, 2011, 12:42:09 am »
Oh, well, I hope so : D

We're animating the granger to be very jiggly when it walks. People that shoot it will feel very guilty!
I sense a bias.

Steam is a pretty good marketing strat. As you can see these forums and trem itself are dead. good shit. Hopefully you guys are great success!
These forums are nowhere near dead. I would say they're even more active than the game itself.
{NoS}StalKer
Quote
<Timbo> posting on the trem forums rarely results in anything good

StevenM

  • Posts: 292
  • Turrets: +40/-33
Re: TremZ: development and discussion
« Reply #34 on: September 22, 2011, 02:57:00 am »
I think if they really want to push the limits of this game and perhaps even make a career out of it. They are going to need much more than these forums and steam may offer that.

I sense a bias.

kharnov

  • Spam Killer
  • *
  • Posts: 626
  • Turrets: +47/-791
    • Unvanquished
Re: TremZ: development and discussion
« Reply #35 on: September 22, 2011, 02:59:23 am »
We won't be making a career out of it. TremZ will stay free and open source.

And yes, you should feel TERRIBLE for shooting at poor friend granger.

bleach

  • Posts: 164
  • Turrets: +121/-40
Re: TremZ: development and discussion
« Reply #36 on: September 22, 2011, 04:10:51 am »
default maps for current trem being: ACTS, Nivius, Nexus, Nano, and Tremor?

acts, the most popular, is basically a killbox slightly modified to take advantage of the strengths of both teams.  it is simple and fun, no one really has a glaring advantage because of this map.  i am not sure how it could be made more "commercial", or professional.

-snip-

A.T.C.S.  -- Get out.

RAKninja-Decepticon

  • Posts: 843
  • Turrets: +14/-679
    • Stupid Videos
Re: TremZ: development and discussion
« Reply #37 on: September 22, 2011, 04:12:42 am »
running on minimal sleep  here, i transposed two letters and didnt catch it when i quickly proofread.
Note 4: The best, although not always easiest, way to deal with trolls is thus: do not respond at ALL in the thread.
Main Rules
4.) No spamming or advertising (includes useless multi-posts and bumps.)
6b.) Do NOT harass other members.
  6c.) Do NOT troll!

/dev/humancontroller

  • Posts: 1033
  • Turrets: +1002/-383
Re: TremZ: development and discussion
« Reply #38 on: September 22, 2011, 04:30:00 am »
acts, the most popular, is basically a killbox slightly modified to take advantage of the strengths of both teams.  it is simple and fun, no one really has a glaring advantage because of this map.  i am not sure how it could be made more "commercial", or professional.
ATCS is one big piece of shit box map. simple and boring (at least after you've played a considerable number of games in Tremulous). the only way to make it more professional is by removing it.

StevenM

  • Posts: 292
  • Turrets: +40/-33
Re: TremZ: development and discussion
« Reply #39 on: September 22, 2011, 04:37:31 am »
We won't be making a career out of it. TremZ will stay free and open source.

And yes, you should feel TERRIBLE for shooting at poor friend granger.

YOU might not want make a career out of it and it may not come in the form of TremZ, but this project may lead to other things you seeeeeeeeee.

edit: the biggest balance issue was always shitty maps imo. they werent designed with balance in mind.
« Last Edit: September 22, 2011, 04:39:16 am by StevenM »

Odin

  • Spam Killer
  • *
  • Posts: 1767
  • Turrets: +113/-204
    • My Website
Re: TremZ: development and discussion
« Reply #40 on: September 22, 2011, 04:41:58 am »
Progress update, 09/21/11

The engine overhauls, finished by this coming Sunday:
  • Modern OpenGL 3.2 renderer, based on XreaL
  • MySQL relational database management system
  • Ruby support for system administrators
  • Newton game physics
  • Built-in IRC lobby
  • Dynamic OpenSSL libraries
  • OGG Vorbis audio decoding
  • OpenAL sound API support
  • OGV Theora compression format
  • In-engine VoIP support
  • Mumble positional audio support
  • Localization for other languages
  • Dropping of the QVM format, support for a .dll and .so architecture
Half of this shit was already in XreaL(or in Trem), you shouldn't take credit for the following:
  • OGG Vorbis audio decoding
  • OpenAL sound API support
  • OGV Theora compression format
  • In-engine VoIP support
  • Mumble positional audio support
  • Dropping of the QVM format, support for a .dll and .so architecture
Dropping of the QVM format is a massive mistake, by the way. I doubt it was your decision though considering XreaL dropped it about 700 commits ago(probably 2 years?).

I have a feeling you added those because it makes your list look bigger.

RAKninja-Decepticon

  • Posts: 843
  • Turrets: +14/-679
    • Stupid Videos
Re: TremZ: development and discussion
« Reply #41 on: September 22, 2011, 06:55:53 am »
acts, the most popular, is basically a killbox slightly modified to take advantage of the strengths of both teams.  it is simple and fun, no one really has a glaring advantage because of this map.  i am not sure how it could be made more "commercial", or professional.
ATCS is one big piece of shit box map. simple and boring (at least after you've played a considerable number of games in Tremulous). the only way to make it more professional is by removing it.
removing it because you are bored with it is silly.  it is more than just a box, it has a few slight variations to the whole box format.  things like the bunker, and the side tunnel.  moreover, it is a great map for beginners, it allows them to learn the game rather than deal with spend a lot of time lost in more complex maps.  the map itself does have a good number of options.  there are many ways you can build.

it seems to me more professional to have at least one such standard and default map, to me.

i'm just a user, though, not a developer.  all i have to offer are my opinions.
Note 4: The best, although not always easiest, way to deal with trolls is thus: do not respond at ALL in the thread.
Main Rules
4.) No spamming or advertising (includes useless multi-posts and bumps.)
6b.) Do NOT harass other members.
  6c.) Do NOT troll!

jm82792

  • Posts: 630
  • Turrets: +9/-34
Re: TremZ: development and discussion
« Reply #42 on: September 22, 2011, 06:59:14 am »
Oh, well, I hope so : D

We're animating the granger to be very jiggly when it walks. People that shoot it will feel very guilty!
Aaah! It's the end of the world as i know it,
I've only animated bipeds! Not quadrupeds :(
I'll get over it eventually.

/dev/humancontroller

  • Posts: 1033
  • Turrets: +1002/-383
Re: TremZ: development and discussion
« Reply #43 on: September 22, 2011, 08:58:07 am »
ATCS is one big piece of shit box map. simple and boring (at least after you've played a considerable number of games in Tremulous). the only way to make it more professional is by removing it.
removing it because you are bored with it is silly.  it is more than just a box, it has a few slight variations to the whole box format.  things like the bunker, and the side tunnel.  moreover, it is a great map for beginners, it allows them to learn the game rather than deal with spend a lot of time lost in more complex maps.  the map itself does have a good number of options.  there are many ways you can build.
ATCS does have that small value that it's hard to get lost on the map. but that is basically the only advantage that ATCS has over other maps like Niveus. the advantages of such other maps are: they give a deeper impression, there are much more ways to build, and the fun lasts longer. these advantages are due to better graphics, larger map sizes, unique areas, and greater complexity. and when it comes to impressing new players, ATCS's shitty design fails, despite ATCS's "ability" to "be easy on n00bs". furthermore, with the introduction of minimaps, even that one advantage of ATCS goes away.

vcxzet

  • Posts: 467
  • Turrets: +21/-13
Re: TremZ: development and discussion
« Reply #44 on: September 22, 2011, 09:37:14 am »
Dropping of the QVM format is a massive mistake, by the way.

It is actually one of the first things to do.
Pure check is obsolete, no use for QVM
You can download Native modules(.dll & .so) files from the server instead of QVM

(Though a warning is required to inform the player about possible malicious use of .dll .so before each DL,
Or you can implement mod signing
Or the client can DL a list of checksums of trusted mods)

Native modules are considerable faster than QVM
Native modules can implement scripting languages for easy modification.

There is no reason to keep it.

gimhael

  • Posts: 546
  • Turrets: +70/-16
Re: TremZ: development and discussion
« Reply #45 on: September 22, 2011, 10:50:48 am »

There is no reason to keep it.


Security.

/dev/humancontroller

  • Posts: 1033
  • Turrets: +1002/-383
Re: TremZ: development and discussion
« Reply #46 on: September 22, 2011, 10:54:29 am »
Dropping of the QVM format is a massive mistake, by the way.

It is actually one of the first things to do.
Pure check is obsolete, no use for QVM
You can download Native modules(.dll & .so) files from the server instead of QVM

(Though a warning is required to inform the player about possible malicious use of .dll .so before each DL,
Or you can implement mod signing
Or the client can DL a list of checksums of trusted mods)

Native modules are considerable faster than QVM
Native modules can implement scripting languages for easy modification.

There is no reason to keep it.
the strengths of QVMs are portability (compatibility, easy deployment of mods) and security. these are lost when dropping QVM support. one can regain these traits by hard-coding the game logic modules into the engine, adding support for a scripting language, and slowly rewriting parts of the modules in the scripting languages, allowing a new method for modding. but this is just an indirect way of transitioning from QVMs to portable, sandboxed programming languages and plugins. this transition does not come with a gain in performance, but allows for more preferred and productive developming later on.

Volt

  • Posts: 256
  • Turrets: +66/-54
Re: TremZ: development and discussion
« Reply #47 on: September 22, 2011, 11:05:10 am »
Progress update, 09/21/11

The engine overhauls, finished by this coming Sunday:
  • Modern OpenGL 3.2 renderer, based on XreaL
  • MySQL relational database management system
  • Ruby support for system administrators
  • Newton game physics
  • Built-in IRC lobby
  • Dynamic OpenSSL libraries
  • OGG Vorbis audio decoding
  • OpenAL sound API support
  • OGV Theora compression format
  • In-engine VoIP support
  • Mumble positional audio support
  • Localization for other languages
  • Dropping of the QVM format, support for a .dll and .so architecture
Half of this shit was already in XreaL(or in Trem), you shouldn't take credit for the following:
  • OGG Vorbis audio decoding
  • OpenAL sound API support
  • OGV Theora compression format
  • In-engine VoIP support
  • Mumble positional audio support
  • Dropping of the QVM format, support for a .dll and .so architecture
Dropping of the QVM format is a massive mistake, by the way. I doubt it was your decision though considering XreaL dropped it about 700 commits ago(probably 2 years?).

I have a feeling you added those because it makes your list look bigger.

lol's i'm not taking credit for inventing this shit, but none of that has been in upstream ever. Yea you see some of it in Tremfusion/FSM-trem but meh out of date. A lot of that stuff like VoIP wasn't complete, no UI triggers, no Menu stuff ect.. I plan to maintain the engine after release and add in stuff I feel is useful. The main reason we chose not to use xreal is because that shit is bloated and the render is meh we don't need all of the features of xreal but some of them are nice. I'd like to point out for future reference, we're using a forked ioquake3 engine with features I find useful from OpenWolf,Xreal,Ioquake3, and other quake based engines.
  
Dropping of the QVM format is a massive mistake, by the way.

It is actually one of the first things to do.
Pure check is obsolete, no use for QVM
You can download Native modules(.dll & .so) files from the server instead of QVM

(Though a warning is required to inform the player about possible malicious use of .dll .so before each DL,
Or you can implement mod signing
Or the client can DL a list of checksums of trusted mods)

Native modules are considerable faster than QVM
Native modules can implement scripting languages for easy modification.

There is no reason to keep it.

LOL'D at Odin's response, thanks for replying saved me the trouble.

There is no reason to keep it.


Security.

Yup :) Also we dropped the md5 code and updated it to sha1 how you like them apples? Not going to have to worry about a well known purification exploit to load custom vm's O.o hehe so hackers are going to have to try harder.

Dropping of the QVM format is a massive mistake, by the way.

It is actually one of the first things to do.
Pure check is obsolete, no use for QVM
You can download Native modules(.dll & .so) files from the server instead of QVM

(Though a warning is required to inform the player about possible malicious use of .dll .so before each DL,
Or you can implement mod signing
Or the client can DL a list of checksums of trusted mods)

Native modules are considerable faster than QVM
Native modules can implement scripting languages for easy modification.

There is no reason to keep it.
the strengths of QVMs are portability (compatibility, easy deployment of mods) and security. these are lost when dropping QVM support. one can regain these traits by hard-coding the game logic modules into the engine, adding support for a scripting language, and slowly rewriting parts of the modules in the scripting languages, allowing a new method for modding. but this is just an indirect way of transitioning from QVMs to portable, sandboxed programming languages and plugins. this transition does not come with a gain in performance, but allows for more preferred and productive developming later on.

The main reason for dropping the current vm system was to make a few well known hacking exploits that Quake/Trem has obsolete. Yea there's still .dll injection but hackers are going to have to start from scratch now if they want to cheat. Even a year or two without any aimbots will allow the community to flourish. We lose some portability and easy development of mods like you said, but we gain some time to deal with hacks and come up with smart deterrent's to players wanting to hack/cheat.
« Last Edit: September 22, 2011, 11:14:49 am by Volt »

Tremulant

  • Spam Killer
  • *
  • Posts: 1039
  • Turrets: +370/-58
Re: TremZ: development and discussion
« Reply #48 on: September 22, 2011, 12:15:56 pm »
lol's i'm not taking credit for inventing this shit, but none of that has been in upstream ever. Yea you see some of it in Tremfusion/FSM-trem but meh out of date. A lot of that stuff like VoIP wasn't complete, no UI triggers, no Menu stuff ect.. I plan to maintain the engine after release and add in stuff I feel is useful. The main reason we chose not to use xreal is because that shit is bloated and the render is meh we don't need all of the features of xreal but some of them are nice. I'd like to point out for future reference, we're using a forked ioquake3 engine with features I find useful from OpenWolf,Xreal,Ioquake3, and other quake based engines.
Using, as in using at present, or hope to be using in the future when it actually exists, what's the current status of your engine(and i do mean your engine, the one that you've forked from ioq3 and added this stuff to, not someone else's that already happens to have the features you want)? Do also note that kharnov mentioned a "Modern OpenGL 3.2 renderer, based on XreaL", which you're saying it isn't.
As for you planning to maintain the engine after release, that's something you personally are capable of, or you hope someone you've convinced to join your team will maintain it after release, having done all the work on it up until that point too?
my knees by my face and my ass is being hammered

vcxzet

  • Posts: 467
  • Turrets: +21/-13
Re: TremZ: development and discussion
« Reply #49 on: September 22, 2011, 12:37:50 pm »
Dropping of the QVM format is a massive mistake, by the way.

It is actually one of the first things to do.
Pure check is obsolete, no use for QVM
You can download Native modules(.dll & .so) files from the server instead of QVM

(Though a warning is required to inform the player about possible malicious use of .dll .so before each DL,
Or you can implement mod signing
Or the client can DL a list of checksums of trusted mods)

Native modules are considerable faster than QVM
Native modules can implement scripting languages for easy modification.

There is no reason to keep it.
the strengths of QVMs are portability (compatibility, easy deployment of mods) and security. these are lost when dropping QVM support. one can regain these traits by hard-coding the game logic modules into the engine, adding support for a scripting language, and slowly rewriting parts of the modules in the scripting languages, allowing a new method for modding. but this is just an indirect way of transitioning from QVMs to portable, sandboxed programming languages and plugins. this transition does not come with a gain in performance, but allows for more preferred and productive developming later on.
if you have no client/server for a system/os then your QVM will not work on that system
Of course it would be PITA for a modder to create all native modules for each system that has a client/server.

Scripting is nice. (lua jit would be my first choice :) ). But exactly what you said...

security is not a real issue if you have a central server that can provide a list of trusted module packages.
you might need a team to test mods for nasties.

QVM was id's second try on quakeC. And they dropped it. I am yet to see a new game using VM.

Take a look at warsow. They are using native modules. A mod comes with an archive(pk3) of modules for different platforms ( which counts for pure check)

gimhael

  • Posts: 546
  • Turrets: +70/-16
Re: TremZ: development and discussion
« Reply #50 on: September 22, 2011, 12:50:21 pm »
Dropping of the QVM format is a massive mistake, by the way.

It is actually one of the first things to do.
Pure check is obsolete, no use for QVM
You can download Native modules(.dll & .so) files from the server instead of QVM

(Though a warning is required to inform the player about possible malicious use of .dll .so before each DL,
Or you can implement mod signing
Or the client can DL a list of checksums of trusted mods)

Native modules are considerable faster than QVM
Native modules can implement scripting languages for easy modification.

There is no reason to keep it.
the strengths of QVMs are portability (compatibility, easy deployment of mods) and security. these are lost when dropping QVM support. one can regain these traits by hard-coding the game logic modules into the engine, adding support for a scripting language, and slowly rewriting parts of the modules in the scripting languages, allowing a new method for modding. but this is just an indirect way of transitioning from QVMs to portable, sandboxed programming languages and plugins. this transition does not come with a gain in performance, but allows for more preferred and productive developming later on.
if you have no client/server for a system/os then your QVM will not work on that system
Of course it would be PITA for a modder to create all native modules for each system that has a client/server.

Scripting is nice. (lua jit would be my first choice :) ). But exactly what you said...

security is not a real issue if you have a central server that can provide a list of trusted module packages.
you might need a team to test mods for nasties.

QVM was id's second try on quakeC. And they dropped it. I am yet to see a new game using VM.

Take a look at warsow. They are using native modules. A mod comes with an archive(pk3) of modules for different platforms ( which counts for pure check)

The quake engine has a platform-independent QVM interpreter.

Volt

  • Posts: 256
  • Turrets: +66/-54
Re: TremZ: development and discussion
« Reply #51 on: September 22, 2011, 01:27:13 pm »
lol's i'm not taking credit for inventing this shit, but none of that has been in upstream ever. Yea you see some of it in Tremfusion/FSM-trem but meh out of date. A lot of that stuff like VoIP wasn't complete, no UI triggers, no Menu stuff ect.. I plan to maintain the engine after release and add in stuff I feel is useful. The main reason we chose not to use xreal is because that shit is bloated and the render is meh we don't need all of the features of xreal but some of them are nice. I'd like to point out for future reference, we're using a forked ioquake3 engine with features I find useful from OpenWolf,Xreal,Ioquake3, and other quake based engines.
Using, as in using at present, or hope to be using in the future when it actually exists, what's the current status of your engine(and i do mean your engine, the one that you've forked from ioq3 and added this stuff to, not someone else's that already happens to have the features you want)? Do also note that kharnov mentioned a "Modern OpenGL 3.2 renderer, based on XreaL", which you're saying it isn't.
As for you planning to maintain the engine after release, that's something you personally are capable of, or you hope someone you've convinced to join your team will maintain it after release, having done all the work on it up until that point too?

Using it presently. The status of engine is now uses .dll+.so files instead of qvm's, updated render system to support iqm+md5,Mysql stuff works, and we can manage bans and admins via ruby on rails. I'm working on getting more features from openwolf into trem it should be done by Saturday hopefully. The only issue i'm running into now is the project won't compile under gcc environments. Because of all the visual studio changes, it takes reworking the makefile which is tedious but possible.  We have the render from xreal but we also have the old render as a fallback on if they can't use the new xreal one. I didn't say it wasn't from xreal what i meant is we're choosing engine features/code from more than just xreal. Currently I'm the one working on the engine and i'm capable of updating it. The stuff I'm adding in now is from xreal+openwolf and some other forks I found. I also got the visual studio build file that has been sitting in trunk to work it has been broken for a long,long time (450 errors that I had to fix to get it working with gpp code). The engine tremz will be running on will take advantage of all the community achievements that have been done in the ioquake3 universe, there is just too much cool code within the community that tremulous should have adopted years ago. I'm lucky to have the help and support system I currently have with the engine stuff. There's some stuff I don't understand engine wise but my support system in ioquake community is strong. Whenever I run into something I don't understand I have people I can go to who can explain it to me, also whenever I get errors I can't fix i have friends who will help me fix the errors. I have people from (openwolf,ioquake3,xreal) helping me port things over  So I'd just like to point out that although I'll be maintaining it I have alot of people to help me when things go wrong It is how opensource is meant to function after all :)

Also here's a list of the most recent devteam standings

Kharnov- Community outreach  
Story board, Game plot,Documentation, responsible for direction
towards back story and storyboard


Volt -Project Lead, Ui Lead, Programming Lead
Code,Ui,Web,Server,Sound,2d assets,Particle System,
Client, Lobby system,Interface Design,Sound Effects, Interlinking of
subsystems.


Kitsune - Customer Support
Cgame,Server,Client, Customer Support, Hosting


Qrntzz - application coding, lobby system, european server hosting

`Ishq - bot coding,Newbie training

gimhael - rendering lead

F1rst19 - Modeling Lead
Human weapon models,Human buildable models,Animations, and human
player models,mapping


Gregstein - Alien Team Head, modeling, Texturing, Annimations

Iciban- modeling/texturing powerhouse with modeling software (guy they ignored)

Karvajalka - 2d art, textures

Redsky - concept art, Painting,Sculpting,Low Poly Modelling (ITS THE FAMOUS REDSKY RETURNED)

Iron1e- Promotional videos (also was ignored)

Duck "c4" - Mapping

Vortexxian - sound engineer (also you'll be hearing his voice in Vsay menus!)
Various sound submissions, is overall just really pro!


ImQ009 - sound engineer
Various promotional sound loops, sound effects, ambient loops


cron - Jack of all trades, does a lot helps out where it's needed.


Contributors

Cow- Bots

jm82792 - can annimate, unwrapp, uv, and texture

Clark - various 2d+web programming

f50 - codding,input

the_medstation - contributor

kynes - contributor

Nux - Modeling,concept art

Seeeker - Modeling and animation

kdude63 - contributor

a_Spork - contributor

Dracone- Providing gameplay ideas - contributor

donated models from cg soceity+ those people - contributors

people from (openwolf,xreal,ioquake3) who help with questions -contributors


There's 2-3 people who have chosen to be left off list until release, but with this powerhouse of talent I don't see why we'd have any trouble getting anything we want done.
« Last Edit: September 22, 2011, 09:53:01 pm by Volt »

vcxzet

  • Posts: 467
  • Turrets: +21/-13
Re: TremZ: development and discussion
« Reply #52 on: September 22, 2011, 01:39:15 pm »
The quake engine has a platform-independent QVM interpreter.

And your point is .... ???

gimhael

  • Posts: 546
  • Turrets: +70/-16
Re: TremZ: development and discussion
« Reply #53 on: September 22, 2011, 04:03:52 pm »
The quake engine has a platform-independent QVM interpreter.

And your point is .... ???

if you have no client/server for a system/os then your QVM will not work on that system

Using DLLs the maintainer of the game server decides which architectures are supported. With QVMs the user can decide this. I understood that you implied the opposite, but I'm no native speaker so maybe I just misunderstood you.

Cadynum

  • Posts: 222
  • Turrets: +29/-13
Re: TremZ: development and discussion
« Reply #54 on: September 22, 2011, 04:37:29 pm »
Uncensored first impressions straight from my mind:
Models look worse than what's currently in 1.1. I would not spend very much time replacing the current models, just use the models planned for 1.2 when they get released.
HUD looks polished, but it's not something I would use in game. Too much irrelevant obscuring the view. Inventory looks weird too.

MySQL, Built in irc lobby, ruby for admins - These things matter very little. They might matter when the game has about 1000 active players. Wait until then before wasting time on it when it can be spent doing better things.


OGV Theora compression format - What's this good for?
OGG Vorbis audio decoding - Is this really needed? Who wants lossy?
Dynamic OpenSSL libraries - What purpose does SSL have in a game like tremulous?


The following features are already in the engine:
Mumble positional audio support
OpenAL sound API support



These are the changes that could matter. Focus on them instead:

Modern OpenGL 3.2 renderer, based on XreaL
Newton game physics
In-engine VoIP support
More maps

   
Dropping of the QVM format, support for a .dll and .so architecture - What are the advantages to this approach?

/dev/humancontroller

  • Posts: 1033
  • Turrets: +1002/-383
Re: TremZ: development and discussion
« Reply #55 on: September 22, 2011, 06:36:37 pm »
OGG Vorbis audio decoding - Is this really needed? Who wants lossy?
OGG-compressed audio files are much smaller in size, and provide a quality that is close to high-quality raw wave files. most audio files in Q3-derived games have a rate of like 22kHz (because 22kHz is an acceptable trade-off with file sizes in mind). use of lossy audio compression can significantly reduce file sizes AND boost quality to, say, a "mid-22kHz-44kHz rate", provided that a high-quality (ie., >=44kHz) file is used as the source of the compressed file.
Dynamic OpenSSL libraries - What purpose does SSL have in a game like tremulous?
1337ness. secure authentication even if the server address changes. security for rcon access with both password-based and public-key-based access granting methods. authentication of code.
« Last Edit: September 22, 2011, 06:38:28 pm by /dev/humancontroller »

vcxzet

  • Posts: 467
  • Turrets: +21/-13
Re: TremZ: development and discussion
« Reply #56 on: September 22, 2011, 08:02:59 pm »
The quake engine has a platform-independent QVM interpreter.

And your point is .... ???

if you have no client/server for a system/os then your QVM will not work on that system

Using DLLs the maintainer of the game server decides which architectures are supported. With QVMs the user can decide this. I understood that you implied the opposite, but I'm no native speaker so maybe I just misunderstood you.


X is the developer of the game.
X needs to compile his game for each platform he wants his game to run on.
X can compile the DLL files for each platform as well.
X actually doesn't really need QVM.

Y is a server side modder.
Y might need to compile his own server for his platform.
Y can compile the DLL files for his platform as well.
Y actually doesn't really need QVM.

Z is a client side modder.
Z needs to compile DLLs for each platform X's game runs on.
Z begs people(including X) to compile his code for a specific platform.
Z actually needed QVM.
Z has a painful life.




Chomps123

  • Posts: 341
  • Turrets: +4/-15
Re: TremZ: development and discussion
« Reply #57 on: September 22, 2011, 08:12:13 pm »
Z is a client side modder.
Z needs to compile DLLs for each platform X's game runs on.
Z begs people(including X) to compile his code for a specific platform.
Z actually needed QVM.
Z has a painful life.
I thought this part was pretty funny.
Don't just live life with work.
Find some time every day to have some fun. ;)

your face

  • Community Moderators
  • *
  • Posts: 3842
  • Turrets: +116/-420
Re: TremZ: development and discussion
« Reply #58 on: September 22, 2011, 08:32:15 pm »
Your face - Mapping Lead
Creating official maps, responsible for direction towards mapping


excuse me? ::)
spam spam spam, waste waste waste!

Tremulant

  • Spam Killer
  • *
  • Posts: 1039
  • Turrets: +370/-58
Re: TremZ: development and discussion
« Reply #59 on: September 22, 2011, 08:46:20 pm »
Your face - Mapping Lead
Creating official maps, responsible for direction towards mapping

excuse me? ::)
What should it read?
my knees by my face and my ass is being hammered