What are you working on?
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: What are you working on?
Guys can anyone help me? I thought QuakeExpo last date to register was 29 of July, not 15! My project is finished(I created site page and youtube video), can you put me in? Pleeeeeeeeeaseeee! I'm Italian, we love to sneak trough when party is already started! LOOOL
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Re: What are you working on?
toneddu2000, you're registered and a booth author! Yes, registration is open til the 29th. Booth might show up 5 minutes before the expo closes, but it will be preserved for all eternity in archive form.toneddu2000 wrote:Guys can anyone help me? I thought QuakeExpo last date to register was 29 of July, not 15! My project is finished(I created site page and youtube video), can you put me in? Pleeeeeeeeeaseeee! I'm Italian, we love to sneak trough when party is already started! LOOOL
Re: What are you working on?
Just an update on ObjectivelyMVC in Quetoo:
Integrating ObjectivelyMVC into the game engine took an interesting turn: the SDL_Renderer API that ObjectivelyMVC uses for all of its accelerated 2D drawing makes quite a mess of OpenGL state. I realized pretty early on that allowing the UI to render within the same GL context that the rest of the game occupies would be fraught with peril (and state leaks). So I decided to try something kind of novel that I've never used before: multiple OpenGL contexts with shared texture objects.
So the game does its rendering in the main context, and then passes off to the UI. The UI makes its own GL context current, renders the user interface to an FBO which is attached to a texture that is shared by both contexts. When the UI is done rendering, it yields back to the primary GL context, where I blit the rendered UI to the screen. It's surprisingly elegant! There was one funny bit. Can you spot it?
Integrating ObjectivelyMVC into the game engine took an interesting turn: the SDL_Renderer API that ObjectivelyMVC uses for all of its accelerated 2D drawing makes quite a mess of OpenGL state. I realized pretty early on that allowing the UI to render within the same GL context that the rest of the game occupies would be fraught with peril (and state leaks). So I decided to try something kind of novel that I've never used before: multiple OpenGL contexts with shared texture objects.
So the game does its rendering in the main context, and then passes off to the UI. The UI makes its own GL context current, renders the user interface to an FBO which is attached to a texture that is shared by both contexts. When the UI is done rendering, it yields back to the primary GL context, where I blit the rendered UI to the screen. It's surprisingly elegant! There was one funny bit. Can you spot it?
Code: Select all
/**
* @brief Renders the user interface to a texture in a reserved OpenGL context, then
* blits it back to the screen in the default context. A separate OpenGL context is
* used to avoid OpenGL state pollution.
*/
void Ui_Draw(void) {
if (cls.key_state.dest != KEY_UI) {
return;
}
SDL_GL_MakeCurrent(r_context.window, ui_context.context);
SDL_SetRenderTarget(ui_context.renderer, ui_context.texture);
SDL_SetRenderDrawColor(ui_context.renderer, 0, 0, 0, 0);
SDL_SetRenderDrawBlendMode(ui_context.renderer, SDL_BLENDMODE_BLEND);
SDL_RenderClear(ui_context.renderer);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(0, r_context.window_width, 0, r_context.window_height, -1, 1);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
$(mainViewController, drawView, ui_context.renderer);
glFinish(); // <-- well fuck my ass
SDL_SetRenderTarget(ui_context.renderer, NULL);
SDL_GL_MakeCurrent(r_context.window, r_context.context);
R_DrawImage(0, 0, 1.0, &ui_context.image);
}
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: What are you working on?
Thanks a bunch, qbism!qbism wrote: toneddu2000, you're registered and a booth author! Yes, registration is open til the 29th. Booth might show up 5 minutes before the expo closes, but it will be preserved for all eternity in archive form.
Here's my project on QExpo 2016, projectUnknown. It's an arena-style multiplayer fps all created by(code, models, textures, sounds, except GLSL shaders) me with FTEQW, featuring: not-so-dumb AI, animated HUD, animated map objects, 3 maps, ragdoll physics, 4 weapons, and a lot more. But, honestly, it's just a proof of concept, that, could be never released, in theory (but I GUESS it will be released in September/October)
YouTube video
projectSite (still in progress)
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Re: What are you working on?
https://www.youtube.com/watch?v=sMLeHLN8kZU
Made a chainsaw this weekend using the Ogre chainsaw model and the hands from loga mira's models. I need to work on the sounds, I'm happy with the idle sound but the others could use some work.
I also finally got round to tidying up and improving a load of the AI code.
Some other things to note in this video:
- ogres now have a run and gun animation, meaning they don't stand still when shooting grenades at you. this happens 50% of the time
- ogre grenades now lead the player a bit taking into account if the player is moving, also if the player is above/below the ogre
- couple of good examples of monsters popping up in unexpected places due to them using the waypointing code to find me!
- you can pick health packs up to take you over 100
- if you're below 100 health, you will regen back to your nearest 20 health (20, 40, 60 80 etc)
- this needs a lot more balancing as currently it's too easy
Made a chainsaw this weekend using the Ogre chainsaw model and the hands from loga mira's models. I need to work on the sounds, I'm happy with the idle sound but the others could use some work.
I also finally got round to tidying up and improving a load of the AI code.
Some other things to note in this video:
- ogres now have a run and gun animation, meaning they don't stand still when shooting grenades at you. this happens 50% of the time
- ogre grenades now lead the player a bit taking into account if the player is moving, also if the player is above/below the ogre
- couple of good examples of monsters popping up in unexpected places due to them using the waypointing code to find me!
- you can pick health packs up to take you over 100
- if you're below 100 health, you will regen back to your nearest 20 health (20, 40, 60 80 etc)
- this needs a lot more balancing as currently it's too easy
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: What are you working on?
You grabbed this (and the overhealing) from Wolfenstein: TNO, and IMO this is pure genius, gameplay wise.c0burn wrote:if you're below 100 health, you will regen back to your nearest 20 health (20, 40, 60 80 etc)
The guys at Machinegames had this dilemma: they needed to cater to both current generation and old school players.
The console approach of "hide behind a crate and wait your health regenerate" was just too lame to us oldfarts.
Spreading medikits around the map wouldn't work with the current generation - they are not used to run and dodge to staying alive. (heh, morons...)
How to solve the situation ? Implement both of the mechanics.
Oldschool players like me will find plenty of medikits around the map, so we can play using our default tatics: circle strafing, jumping and guns blazing.
OR... give the console generation a sugar spoon: let them hide behind some crate and wait to regen... but just enough to run to the next safe spot OR the next medikit. Either way, they have some time to think about the next move, but just sitting and waiting won't help them.
That's the kind of gameplay I would expect from a single player Quake remake.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: What are you working on?
Indeed, nice way of mixing things up.
Some other healing ideas inspired by rpg and fighting games:
* Tie the regen amount to armor, eg. 20 armor = generate up to 20 health (relative or absolute).
* Have enemies drop health, but a la Q2 inventory items which can be activated on demand, combine that with a cooldown time for each usage.
* Introduce new fodder-baddies that always drop a certain item when killed, so they become walking/flying items essentially, could be cool for mappers to set up battle that way.
Nice mod
Some other healing ideas inspired by rpg and fighting games:
* Tie the regen amount to armor, eg. 20 armor = generate up to 20 health (relative or absolute).
* Have enemies drop health, but a la Q2 inventory items which can be activated on demand, combine that with a cooldown time for each usage.
* Introduce new fodder-baddies that always drop a certain item when killed, so they become walking/flying items essentially, could be cool for mappers to set up battle that way.
Nice mod
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: What are you working on?
Great work c0burn! WIll you replace also quake enemies models with doom ones? Chainsaw is fantastic!
One thing I didn't understand: why video title is "Quakespasm ..etc"? Isn't your mod a quakec mod, usable on every engine? Or is it also a preview of new QuakeSpasm release?
One thing I didn't understand: why video title is "Quakespasm ..etc"? Isn't your mod a quakec mod, usable on every engine? Or is it also a preview of new QuakeSpasm release?
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Re: What are you working on?
This is exactly where it's inspired from. I'm just worried about balancing it.frag.machine wrote:You grabbed this (and the overhealing) from Wolfenstein: TNO, and IMO this is pure genius, gameplay wise.c0burn wrote:if you're below 100 health, you will regen back to your nearest 20 health (20, 40, 60 80 etc)
The guys at Machinegames had this dilemma: they needed to cater to both current generation and old school players.
The console approach of "hide behind a crate and wait your health regenerate" was just too lame to us oldfarts.
Spreading medikits around the map wouldn't work with the current generation - they are not used to run and dodge to staying alive. (heh, morons...)
How to solve the situation ? Implement both of the mechanics.
Oldschool players like me will find plenty of medikits around the map, so we can play using our default tatics: circle strafing, jumping and guns blazing.
OR... give the console generation a sugar spoon: let them hide behind some crate and wait to regen... but just enough to run to the next safe spot OR the next medikit. Either way, they have some time to think about the next move, but just sitting and waiting won't help them.
That's the kind of gameplay I would expect from a single player Quake remake.
Thank you! I wasn't planning on having arnour in this mod, as I find it pretty dull. I'm definitely planning on some cool powerups though. I like the idea of certain monsters dropping items, I might make a certain variety ogre that always drops his chainsaw.Spiney wrote:Indeed, nice way of mixing things up.
Some other healing ideas inspired by rpg and fighting games:
* Tie the regen amount to armor, eg. 20 armor = generate up to 20 health (relative or absolute).
* Have enemies drop health, but a la Q2 inventory items which can be activated on demand, combine that with a cooldown time for each usage.
* Introduce new fodder-baddies that always drop a certain item when killed, so they become walking/flying items essentially, could be cool for mappers to set up battle that way.
Nice mod
Nah, this isn't a DOOM IN QUAKE mod, but the weapons so far are certainly highly inspired by Doom. The video title is because its running in quakespasm, and I captured it using the inbuilt windows 10 capture and was too lazy to renam eit. it should be useable on any NQ engine as I'm not targeting any QC extensions.toneddu2000 wrote:Great work c0burn! WIll you replace also quake enemies models with doom ones? Chainsaw is fantastic!
One thing I didn't understand: why video title is "Quakespasm ..etc"? Isn't your mod a quakec mod, usable on every engine? Or is it also a preview of new QuakeSpasm release?
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: What are you working on?
Windows 10 has builtin capture? Didn't know that! Wowc0burn wrote:using the inbuilt windows 10 capture
Meadow Fun!! - my first commercial game, made with FTEQW game engine
Re: What are you working on?
Win+Gtoneddu2000 wrote:Windows 10 has builtin capture? Didn't know that! Wowc0burn wrote:using the inbuilt windows 10 capture
-
- Posts: 1395
- Joined: Tue Feb 24, 2009 4:39 pm
- Location: Italy
Re: What are you working on?
@c0burn: thanks man! As soon as I get my pc back, I'll test it!
@Barnes: I kinda like cross belt, but I want to see super high poly models to test q2xp engine rendering features!!
@Barnes: I kinda like cross belt, but I want to see super high poly models to test q2xp engine rendering features!!
Meadow Fun!! - my first commercial game, made with FTEQW game engine
-
- Posts: 2126
- Joined: Sat Nov 25, 2006 1:49 pm
Re: What are you working on?
This is a WIP map designed for SDQ and intended to be finished in time for QExpo, but... let's say that real life truly sucks sometimes.
OTOH without the schedule pressure I was able to add more details and a couple secret areas, yay.
OTOH without the schedule pressure I was able to add more details and a couple secret areas, yay.
I know FrikaC made a cgi-bin version of the quakec interpreter once and wrote part of his website in QuakeC (LordHavoc)
Re: What are you working on?
Implemented 32-bit mipmaps for 8-bit textures, support for 8-bit alpha channels from 32-bit textures, and external glow/luma textures.
Also, my mipmap generation algorithm actually doesn't have gamma correction yet. When MH suggested gamma correction earlier in this thread, I thought he was talking about RGB value normalization to avoid losses when rounding down the blended values. Afterwards I've done some good research and learned what gamma correction actually is. I'm going to implement this soon.
Also, my mipmap generation algorithm actually doesn't have gamma correction yet. When MH suggested gamma correction earlier in this thread, I thought he was talking about RGB value normalization to avoid losses when rounding down the blended values. Afterwards I've done some good research and learned what gamma correction actually is. I'm going to implement this soon.