skew

It's a multiplayer mod for Jedi Academy MP. It's intended as 1v1 for a 2/3 round structure of matches. It picks a pair of people to play for each match. It supports clients and bots with a new fighting game AI. Unfortunately you won't find any servers yet since it's still in development. You can find more info here: https://www.moddb.com/mods/jedi-fighter/downloads

Hey guys, It's been a few years since my last update but I will be trying to work towards a release soon. Quick update: - Trying the built in saber knockbackScale as a hitstun with my own damage system. Video below. It seems to work well enough, but it breaks the knockdowns from kicks and, in certain cases, results in ridiculously far knock backs, so I'll be adding a knock down when the knock back exceeds a threshold.

What a great idea. Thanks for doing this, Circa. I watched a portion but will check the rest out over this week. Thanks to the staff and the community for keeping this site vibrant. It's much appreciated, even by sporadic lurkers like me!

If I go with hitboxes, then I'll definitely be doing weak zones. Also looking at my special move system right now to see how I can do chains/combos. I wrote a scripting system for special moves which I'll include commands to create or delete zones of a certain type at a given time during move execution, which is how I'll do the hitboxes without resorting to per frame info. For chains/combos, I've got a permissive check in the special move script. When an input combo is matched, it'll check permissives before executing the remainder of the move. In the permissives I'd add the moves one must be in to perform the chained move, but this might not be the final approach. Just working on some concepts.

Fighting game fans are pretty opinionated about how hit detection is done and it can be a major factor in their enjoyment of any given fighting game. Traditional fighting games use one of two methods, 1) hit boxes, or 2) sprite/model based collision detection. I'd like to hear the community feedback on which hit detection approach you prefer and why. I'm considering whether to improve the standard JA collision detection or switch to hitboxes in Jedi Fighter. Hit boxes Hit boxes are basically collision zones (usually a set of boxes) that define the regions of the character which can cause damage (e.g. a leg during a sweep kick) or take damage (i.e. the head while executing a kick). Some variations on this approach are to handcraft or automatically generate the hitboxes per frame of animation, or to use hit spheres/circles rather than boxes. For the purposes of this poll, hit boxes are any metadata defining collision zones that don't match the model/sprite. Many 2D fighting games like Street Fighter II use hit boxes. Some reasons cited for using hitboxes: - to provide consistency of the hit detection zones during idle animations - to keep a hit box fixed while taking damage during a knockback animation so the opponent can execute chained attacks - to define weakness locations during an attack - they provide a method to fine tune and balance the hit detection Examples shown below: Street Fighter II/Turbo/Championship hitboxes Hitboxes from Garou: Mark of the Wolves Examples of hitboxes in 2.5D and 3D fighting games are shown below. Super Street Fighter IV Collision detection The traditional approach for JA is per poly collision detection using the Ghoul2 animation system. This means that the actual polygons of the model are used to determine the collisions against weapons, once the weapon/projectile has penetrated a certain box around the player. You get whatever the animation gives you. Some reasons cited for per poly collision detection are: - less development effort since collision zones are determined by the model directly - collision detection matches how the player looks, so it appears more "accurate" and "realistic" - it is technically more realistic I don't have any art to provide for this type of collision detection but I think this one is pretty straight forward. I'd love to hear which method you all prefer to play with and why! What is Jedi fighter?

New, shorter, teaser trailer just went up

I'm trying out a depth based blur now, and you're right that it was really difficult to notice. I made a few changes and will post some shots soon. Looks much more natural now. I'm also working on getting post processing effects to properly show up in mirrors. Here is a test compositing them to the scene image rather than directly to the framebuffer if it's a mirror. When I tried putting it directly to the framebuffer after rendering the portal surface, it never seems to persist in the framebuffer for some reason. Need to figure out why the colors seem off on the blur when compositing to tr.sceneImage though... format issue? EDIT: Also temporarily fixed the issue with the improper scissoring of mirrored surfaces (see previous screenshots) by temporarily disabling the scissoring, but this needs a proper fix. From a cursory check, it looks like the mirrored surface is being split into multiple surfaces. It also looked like, since none of the vertices of the nearer surface are in the frustum, then it culls them entirely rather than checking if the surface exists in the frustum and clipping it to the view. It was then calculating the scissoring coordinates from the remaining verts in clip space, which is only the further half of the mirror surface. I'm going to do more debugging on that to see what is exactly happening, but just another thing to eventually get right.

Thanks, I really appreciate it. Positive feedback like this always helps to keep up the motivation Just noticed that I forgot to update the credits (forgot to put you down for the Luke model, and left out quite a few others) in the Youtube trailer so putting up a new version today. EDIT: The new trailer is up with higher bitrate encoding too, so no more oddly skipped frames!

Any thoughts on what you'll be doing? I'm using OpenJK for a mod that relies heavily on gamepad support...

Hey Everybody, I've been working on a 2D fighting game mod called Jedi Fighter. I just released a beta 3 yesterday, which was mainly focused on making new adaptive fighting game AI. Previous releases relied on JA AI for everything. No more! Check out the mod's profile on moddb: The new AI is loosely Bayesian based and learns on the fly which move to execute next, based on the relative position, health, and absolute health of self and the opponent. It works pretty well, as you can see in the following terrible trailer video: In the next few weeks, I'll post a lot more detail about how the AI and various other features work. Soon I'll be releasing the full source on github too. I'd really appreciate if you guys would try it out, or at least give some comments from the video. Many of the models came from you guys and other talented modders, without which my mod wouldn't have the presentation, so I'm really appreciative that you let me use your assets in Jedi Fighter! Thanks! ------------ BEGIN MARKETING ------------- Features in beta 3 Fight as 10 characters from the Star Wars movies and expanded universe, each armed with unique force powers and devastating special movesFight in 5 arenas, from a Tie hangar bay, to turbolifts in the Deathstar, to the aftermath on HothNew fighting game artificial intelligence, enabling fighters to learn and adapt from opponents on the fly! (new in beta 3)Gamepad support! (improved in beta 3)Full widescreen support for 16:9 (1080p and 720p), 16:10, 4K and 21:9 resolutions! Or any custom resolution!A dynamic camera that gives a cinematic view of the actionAwesome title musicand much, much more!Feedback Your honest feedback is incredibly important and very much appreciated! Please post comments to theforums. I'll be checking them regularly so your comments will help shape the direction of the mod! If you would like to contribute by making maps, please reach out to me via email or messages, or post to the forums. I'd appreciate the help! Requirements: You'll need to install Jedi Academy, the OpenJK engine, and Jedi Fighter beta 3 to play. OpenJK download link: Jedi Fighter beta 3 download link: Installation: Check out these installation instructions to get started. Unzip both Jedi Fighter beta 3 and the OpenJK engine to your Jedi Academy\gamedata directory. Right click on SETUP.BAT in the Jedi Academy\gamedata\jedifighter directory and choose "Run as Administrator".Run JF_CLIENT_OJK.BAT in your Jedi Academy\gamedata\jedifighter directory to get started. Configure your controls, max out your video settings and resolution, and have fun! If you have any issues, check out the detailed instructions in jedifighter\_README_.txt. If you still have problems, feel free to post in the forums. Future plans: JEDI FIGHTER will continue to be improved until the v1.0 release in 2016, with a beta 4 in the next few months. Beta 4 will focus on a few key areas: balancing and adding fighters (including from Star Wars: The Force Awakens)improved user experience with the server browser and match making ----------- END MARKETING -------------

Tried a Gaussian blur on the ssao result and it doesn't look too bad. Going to try a bilateral filter next because it's supposed to preserve edges better. Without SSAO: With SSAO + 2d Gaussian blur:

I do want to learn more about modern OpenGL so I'm interested in helping out with what little time I have . I started looking through the renderer source code to see how it was binding textures, providing data to the shaders, etc and generally walked through bits of it to get an understanding of the flow. The mod I'm working on could really use a modern renderer, and is using the refraction with force push/pull, but also reflections, weather, and at least the SSAO. Let me get past my next beta release in about a week and then I'll try to jump back into rend2. EDIT: Thanks for the info re: ioq3. I was about to try that out to see if they evolved it any beyond the old rend2 used as a basis for the OpenJK version. Looks like the blur on the SSAO output is how most people make it look better.

(Excuse the giant images!) SSAO seems to have an odd screen door effect, almost as if the direction vectors around each normal were following a strong pattern rather than being pseudo-random. Below is a screenshot of the latest rend2 branch from yesterday. When I visualized the random function from the ssao fragment shader( using the fragment coordinates in screen space as the seed just as rend2 at runtime), there is a clear non-randomness to it, similar to the vertical striations from the screenshot. I tried increasing the random vectors per fragment from 3 to 9 to see if it could smoothen out the pattern but it didn't help as much as I wanted. Ultimately I went back to the source referenced by the shader to see if it was an implementation issue. Looks like the random function was done per the source originally but then changed to what is now. // Input: It uses texture coords as the random number seed. // Output: Random number: [0,1), that is between 0.0 and 0.999999... inclusive. // Author: Michael Pohoreski // Copyright: Copyleft 2012 :-) // Source: http://stackoverflow.com/questions/5149544/can-i-generate-a-random-number-inside-a-pixel-shader float random( const vec2 p ) { // We need irrationals for pseudo randomness. // Most (all?) known transcendental numbers will (generally) work. const vec2 r = vec2( 23.1406926327792690, // e^pi (Gelfond's constant) 2.6651441426902251); // 2^sqrt(2) (Gelfond-Schneider constant) //return fract( cos( mod( 123456789., 1e-7 + 256. * dot(p,r) ) ) ); return mod( 123456789., 1e-7 + 256. * dot(p,r) ); // adnan - this gives a strange screendoor effect because the random numbers have vertical banding } Here is what it looks like if I change it back to the original method ( fract( cos( mod( 123456789., 1e-7 + 256. * dot(p,r) ) ) ) ) and with 9 vectors per fragment. Looks much better. This method is obviously more compute intensive only because I've got it doing the 9 vectors per fragment, but seems to work decently on my machine. I'm going to look at doing what Nvidia mention in some of their papers, which was to interleave the selection of vectors from a larger predefined Poisson distribution to get something closer to random, by using the same random number generator to pick vector indices from the set of 9 predefined ones and see if that improves the screendoor effect even further. Others also did a blur to the resulting values to get it to look smoother, so may explore that too. If it ends up working out, I'll update it in my fork of rend2 and will probably post a pull request!

Yeah, it was on my old site (skew.telefragged.com) which is now down, so I need to get it from my archives. I'll post it by next week.

Here are the type of vehicle attributes that were slurped in from a text file. It was stolen from a mod I was making for RTCW, which was a top down vehicles game based on code I started for Combat Quake III Arena (itself a remake of Atari's COMBAT! for Q3)... I loved having so many Q3 engine based games at the time, since you could make your code completely portable between games. vehicles 5 { vehicle deathstar { type tank stats { health 100 armor 200 } weapons 1 { weapon panzerfaust 20 } display { turretmodel models/deathstar/deathstar.md3 basemodel models/deathstar/deathstar.md3 turretshader models/tanks/photon/bluespin baseshader models/tanks/photon/blue turretskin none baseskin none } sound { movesound1 tanks/panzertank/sounds/movesound1.wav movesound2 tanks/panzertank/sounds/movesound2.wav } physics { type treads width 30 height 15 maxspeed 240 } } vehicle tiefighter { type tank stats { health 100 armor 100 } weapons 1 { weapon mp40 200 } display { turretmodel models/map_objects/imp_detention/tie_fighter.md3 basemodel models/tanks/photon/lower.md3 turretshader models/tanks/photon/redspin baseshader models/tanks/photon/red turretskin none baseskin none } sound { movesound1 tanks/panzertank/sounds/movesound1.wav movesound2 tanks/panzertank/sounds/movesound2.wav } physics { type treads width 30 height 15 maxspeed 320 } } vehicle stardestroyer { type tank stats { health 100 armor 200 } weapons 1 { weapon venom 2000 } display { turretmodel models/ships/test.md3 basemodel models/tanks/photon/lower.md3 turretshader models/tanks/photon/greenspin baseshader models/tanks/photon/green turretskin none baseskin none } sound { movesound1 tanks/panzertank/sounds/movesound1.wav movesound2 tanks/panzertank/sounds/movesound2.wav } physics { type treads width 30 height 15 maxspeed 240 } } vehicle jesustank { type tank stats { health 100 armor 200 } weapons 3 { weapon panzerfaust 20 weapon venom 2000 weapon mp40 200 } display { turretmodel models/tanks/panzer/head.md3 basemodel models/tanks/panzer/lower.md3 turretshader models/tanks/panzer/default.tga baseshader models/tanks/panzer/default.tga } sound { movesound1 tanks/panzertank/sounds/movesound1.wav movesound2 tanks/panzertank/sounds/movesound2.wav } physics { type treads width 30 height 15 maxspeed 240 } } vehicle ewing { type tank stats { health 100 armor 200 } weapons 1 { weapon venom 2000 } display { turretmodel models/ships/ewing/ewing.md3 basemodel models/tanks/photon/lower.md3 turretshader none baseshader none turretskin models/ships/ewing/ewing.skin baseskin none } sound { movesound1 tanks/panzertank/sounds/movesound1.wav movesound2 tanks/panzertank/sounds/movesound2.wav } physics { type treads width 30 height 15 maxspeed 240 } } } Anyway, I would support a combat flight sim if someone were to make one. I might be able to contribute in a few months too.