[Wolfenstein: Blade of Agony] v3.1 released (p204)

[RockstarRaccoon]

So... I've been poking at this stuff that Wiw requested when I have to sit through boring things...

Also, this.


Like I said, all I'm doing is scaling them up and smoothing the edges so they look less pixelated on screen. If someone else wants to actually detail these things, they're welcome to do that.

[Gez]

Sincerely, I much prefer the pixels, then.

[Nash]

High resolution sprites don't really work well with 2.5D games, I find. I was experimenting with this for a VERY long time (a few months). In the game I'm currently making, I use 3D models to pre-render my sprites. Hey it's not clay but it's still pretty much the same concept as how Doom's monsters were made. Anyway, I tried a few things. First, I went for high resolution sprites... I rendered my characters to be 200 pixels tall-ish and scale them down in their Actor definition.

Okay, looks good... but now the animations look horrible. I can't really explain why but the more crisp the sprites are, the more "fake" they'll look. I guess it's kinda like if you render real-time 3D characters... the more realistic you render them with skin shaders, lighting, shadows, 4k skin textures etc etc... the harder it is to animate them so that you don't think you're looking at a computer-generated person.

Okay so animation looks crap, so I increased the animation frames by a lot. 18-frame walk cycles and what-not. Now the workload just increased unreasonably, and I had to fight with Doom's archaic sprite naming convention because I need a LOT more sprite names to work with.

This all took a long time because I was constantly adjusting the light rig, the actual modeling and textures to make something look good when rendered at 200 pixels talls.

Finally I said you know what? Fuck it I'm just going to push out renders that are as tall as the Doomguy (56'ish pixels tall). Had to remodel the characters to be a little more fat. On the plus side, only 4 frame walk cycles, and I don't need to work too hard on the textures, because at such a low resolution, tiny details will be lost.

The result? When played in-game, it actually looks and feels like the oldschool graphics made for the engine. It just feels and looks right, despite being really blocky and pixelated and having 4 frames of animation. Here's what they look like, and I've never been happier with my renders:

---

Sorry for the tl;dr, just shared my experience developing graphics for our beloved game engine!

[RockstarRaccoon]

This is a good point. I think the two things at play here are that some people are interested in the retro feel of the ID Tech 1 engine, while others are interested in the ease and elegance of using it: I can make a sprawling map that looks good in Doom Builder in about a 5th of the time as the Source engine devkit. The other thing is that, when a project like this HAS those higher-fidelity graphics, the there's a temptation to alter the pixelated ones to be more crisp. That's really why I'm bothering to do this.

I like your point about the time investment too: it's why in my own current Doom project, I'm only bothering with higher resolution on things like the HUD which will be in front of the player for extended periods, and why I'm only offering to do something like this with the items and stuff.

Really though, alot of this is a matter of preference with aesthetics. I'm just throwing the hi-res sprites together when I'm listening to lectures or waiting for my turn in a tabletop game, and I'm posting the PK3 I've been using as I play through the game here when I'm done in case anyone else wants to use the rounded sprites or take a whack at it themselves...

Edit: Oh! I should also point out that the only computer I have which can run this without the FPS slowing to an unplayable level is a developer-issue iMac with a 32 inch screen and over 2K res: doom games get VERY pixelated on this thing, so much that it starts to mess with my perception of what's happening as everything turns into a mush of pixels if I don't have some higher res content. I can't even watch MLP full-screen on this thing unless it's a 1080P file with something more than nearest neighbor interpolation if I want it to look smooth and not see the pixels. That's probably affecting my perception of the matter.

[CeeJay]

High resolution sprites don't really work well with 2.5D games

I beg to differ. High-resolution graphics can work well if EVERYTHING is of the same or equal scale (including sprites, walls, etc.), and because it's high-res it helps if both the quality and art style is consistent too.

[Tormentor667]

I beg to differ. High-resolution graphics can work well if EVERYTHING is of the same or equal scale (including sprites, walls, etc.), and because it's high-res it helps if both the quality and art style is consistent too.

Confirmed.

[Rachael]

I beg to differ. High-resolution graphics can work well if EVERYTHING is of the same or equal scale (including sprites, walls, etc.), and because it's high-res it helps if both the quality and art style is consistent too.

Confirmed.

Thirded.

I actually play certain vanilla mapsets with a hi-res sprite pack or voxel pack because it helps to enhance the feeling of the mod.

[zrrion the insect]

Redneck Rampage is just about the only thing I ever saw with hires textures/graphics that looked good.

[CeeJay]

Well, compared to DOOM all Build-engine games had hi-res art. Redneck Rampage was the one that pushed it even further. The best looking one, in my opinion, was Blood. To put it into perspective, a typical enemy sprite seen in a Build game is about the size of a Cyberdemon from Doom. The console ports of Wolfenstein 3D is another example, where the 64x64 resources were replaced with 128x128 counterparts. Even if a lot of stuff was left out if looked pretty neat with its charming art style.

[Siberian Tiger]

hey dudes went to run build with the latest GIT been a while >_>

the batch comes back with this :

The system cannot find the batch label specified - PromptUserInput


on windows 10 which could be the issue

edit: same issue on Win7 also.

Hallo,

Sorry it has taken me so long to get back to you, I have been extremely busy with my classes - I have a rare moment to breathe right now.

With the Batch script, can you tell me exactly how I can reproduce the same error (step-by-step)? And please include how you first execute the program in your steps, this way I can follow along and determine what could have caused this error.

Must go now, I'll try to get back you when I possibly can

regards,

[RockstarRaccoon]

Thoughts/Feedback on C1M3: Operation Overlord
- This level had alot of ambitious stuff, and alot of it was pulled off well. I liked just how much you had going on here.
- These hidden gun placements need refinement. They will sometimes take up to 50% of your health as you go down what seems like it's meant to be a safe corridor in the trench area, and end up shooting at me when I'm halfway across the map in the railroad area or the tower. At the end of the map, they created a health-gate where I needed at least 60% health to deal with the one pointing straight down the first trench AND the ambush right over that ridge. They were the most frustrating part of the map.
- When I rode that elevator up into the Tower area, I stopped to screw with it with the map open: that was a really cool effect!
- I also really liked all the vent stuff there.
- In the tower area, what's the point of the mines? They made me look around for a secret or something, but they really didn't add much to the area.
- The area where the railroad goes into what looks like a town: simply walking over to the edge and looking at it, it's very easy to see the cutoff. You should extend the railroad and maybe add another wall to make it less obvious that it's fake.
- Nearby, in the area with the pit surrounded by the fence with one of the Artillery placements, you can walk through the trees around the outside of the fence all the way up to the horizon.
- I got really turned around for a while in the underground hangar behind that door that shorts out where you have to go around through the vents to get in. It took me a while to tell the door into that lab from all the fake ones.
- It took me running around the map for a while to realize that there was an artillery point that I had to run along the beach for, as it seemed like it would kill me pretty quickly to run out there.
- The machine-gun-placement guys are kind of buggy: I'm never sure what will actually damage them. Sometimes I shoot straight at them or toss a grenade and nothing happens, but if I shoot around a corner at their side it seems to be the only reasonable way to handle them.

[RockstarRaccoon]

Hey, I just noticed that the latest stuff on Github requires an indev release of ZDoom for the ZScript-based dialogue...

Is that stable? My understanding was that ZScript was still subject to change...

Edit: Actually, I'm having trouble getting it to run in the latest indev Mac build of 2.4... Are you guys SURE you're using stable ZScript?

[AFADoomer]

Hey, I just noticed that the latest stuff on Github requires an indev release of ZDoom for the ZScript-based dialogue...

Is that stable? My understanding was that ZScript was still subject to change...

Edit: Actually, I'm having trouble getting it to run in the latest indev Mac build of 2.4... Are you guys SURE you're using stable ZScript?

I noticed that today as well...

Graf added version checking for ZScript after the new menu was added to the repository.

Adding the 'version "2.4"' line to the top of zscript.txt fixes the error and lets the game load, but now all of the decorate code spews warnings (and seems to add to load time)... Not sure how that should be dealt with right now. It's "fixed" in the repository, so the game at least loads now...

I need to wait for tomorrow's dev build with updated deprecation checks and other additions to test more.

[RockstarRaccoon]

Ah yes, I noticed it was your commits that were doing it...
Alright, I'll go see if I can get it to work now.

[AFADoomer]

Tomorrow's dev build should fix the warnings, but will break again because of the last change made today (menus changed to use event responder code). One function needs to be re-written (I've already done it, just can't test right now because I need a build that includes those changes).