Is your current drawing system doing a colored quad (or cube, or whatever) for each pixel in the original display? That's probably going to be pretty slow even when compiled into a display list. My OpenGL is rusty and outdated and I've never had to push performance, but I'm pretty sure there's some mechanism for "do this operation once for each point in this provided array". Then you'd just compile a set of arrays, one per color, and tell OpenGL to draw one square (or cube, or whatever) per vertex in each array.
You're correct about my current implementation. I have considered doing edge detection, and only rendering the sides if they bump up against the background color. That would enable me to render only a front facing square instead of all six sides if it's surrounded on four sides by a non-background colored pixel. Should result in some significant savings. Although, it may look weird if/when I add some translucency to the voxels.
Yeah, I wouldn't rush into hacks like that just yet. Consider also that you might want to try e.g. a beveled voxel mode (where each pixel is "rounded" at the edges). Keep things pure for now.
You should take a look at glDrawElements. I think that's the function I was referring to earlier where you just hand it an array of vertices and it does a bunch of drawing for you. All you need to do is call it with GL_TRIANGLES and an array of vertices that specifies all the triangles you want (presumably 12 triangles per voxel, so 36 verts per voxel). I think your workflow then would look something like this:
Arrange all displayed pixels by their color
for color in colors:
vertArray = []
for pixel in pixels of that color:
pixelVerts = generate vertices for a voxel at pixel's position
append pixelVerts to vertArray
glColor3fv(color)
glDrawElements(GL_TRIANGLES, number of pixels * 12, GL_UNSIGNED_INT (probably), 0)
No guarantees that this will actually work; I'm no OpenGL expert. But it seems like the path you'll want to be taking to improve your performance.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Sounds like the applet would be helpful for prototyping, and then you'd try to build the actual thing once you got something working in the applet. At least, for the simpler circuits. When I was in college I took one digital engineering course that had an awful (seriously, the UI was a trainwreck) computer-aided design program for setting up circuits that served a similar purpose.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
If all you want to do is pan/rotate/scale/etc the display, then the simplest approach would be to render the emulator to a texture, and then play with that on a textured quad. But I'm guessing you knew that already and have bigger plans.
Is your current drawing system doing a colored quad (or cube, or whatever) for each pixel in the original display? That's probably going to be pretty slow even when compiled into a display list. My OpenGL is rusty and outdated and I've never had to push performance, but I'm pretty sure there's some mechanism for "do this operation once for each point in this provided array". Then you'd just compile a set of arrays, one per color, and tell OpenGL to draw one square (or cube, or whatever) per vertex in each array.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
This is probably a stupid question, but you are calling SDL_GetMouseState each time you want new values, right? When you pass x and y to another function, they get copied by value, creating new variables in a different part of memory, that won't be modified when another bit of code calls SDL_GetMouseState.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
You should drop in on this thread; dwangoAC and True are both trying to do similar things. It's great to hear you were successful!
Oh, and welcome to the forums. :)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
In particular it's interesting how every single tap by the player's machine, no matter how slight, seems to provoke the other machine to explode. It is possible to one-hit-kill other machines in this game, but in unassisted play you won't ever do it so casually. I'd be curious to hear more about exactly what the mechanics are for "combat".
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Would be nice if you put those information to the game resource page on TASvideos wiki
I don't really see the point in duplicating information that's already available on Sonic Retro, but a link to their resources wouldn't be unreasonable.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I assume that "Win32" earlier meant using Microsoft's GUI libraries directly; in that case the "32" just means "not 16-bit", so it should be compatible with 64-bit machines just fine. That does still leave you with cross-platform compatibility issues. Plus, the various widget libraries tend to make writing GUIs a hell of a lot less painful than trying to do things by hand.
Yeah, Microsoft's naming schemes don't always make much sense, but oh well...
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I'd suggest avoiding Win32 just for cross-platform compatibility concerns. I've made extensive use of wxWidgets at work, and it's reasonably competent. In my experience, it doesn't make exactly the same UI on different platforms (i.e. the exact sizes and positions of elements will be different), but for the most part it works fine.
Qt is also a popular option. I'm not so fond of it mostly because the installer is gigantic (not an issue for users, who don't have to install it) and getting it working in Python, my language of choice, was a bit of a pain (ditto).
I haven't used GTK.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Hell, you have an entire keyboard to play with; there's no reason why you couldn't have a save slot for every single letter, capitalized letter, and symbol.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
They should have made "free software: The game and all its assets will be released as free software under the GPL license" or similar a stretch goal. After all, the game is being paid for up front, and hence they do not depend on monopoly over distribution to make money. Just set the stretch goal high enough that they make a good profit on that alone.
While there are plenty of people who would love to see that, I can't help but think it wouldn't be anywhere near as motivating as their existing stretch goals. The stretch goals are mostly there to encourage people to contribute (or to contribute more, for those who have already pledged). GPLing everything would also be a lot of extra work for the programmers and lawyers (who have to organize everything, make certain they don't accidentally release any code they don't have the license for, go through looking for swear words, etc.) and relatively little for everyone else, which makes for an unbalanced use of the company's time.
But I would love to see all the mods and new games that such an action would result in. :)
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
That slow-motion Death Race video is fantastic. It's amusing to see how conservation of momentum is completely not preserved, and how minor taps with the machine while in a side-shift can prove fatal (while slamming into walls, other machines, etc. head-on normally just takes off about a third of your health).
Nice work!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I've always liked SNES9x's approach to savestates, at least when playing games. You get a 4x3 grid of screenshots, each corresponding to a savestate, and you can navigate the grid with your controller. I use a PS2 controller with save/load state bound to the Start and Select buttons, so I can easily interact with savestates without ever having to put down the controller to type something.
For TASing, odds are you won't be using a controller anyway, so typing is not as much of an issue. Having some streamlined method to support arbitrary, reasonably-labeled savestates makes sense. I'd suggest that when you hit the loadstate button, the emulator should bring up a list of all savestates you've made; you can start typing and it'd automatically winnow down the list based on what you've typed. Then you can tab-complete to finish the names. For example:
>>> [hit loadstate button]
boss1
boss2
cave
gamestart
level1
level2
stupidautoscroller
>>> b
boss1
boss2
>>> [tab]
>>> boss
boss1
boss2
>>> boss1
boss1
>>> [enter]
loaded state "boss1"
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Over 11000 people have backed the Shantae kickstarter. :)
But yes, I'm one of them. I stopped buying handheld consoles after the DS, which meant missing out on their more recent titles, so this'll be the first one I'll have played since the GBC Shantae. I'm looking forward to it!
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
I suspect this is one of those games where it'd be very hard to tell what is intended and what counts as a glitch. For example, several of the big jumps in the first level (Emerald Coast) skip massive chunks of the level but as far as I'm aware, all you need to do to pull them off is be willing to jump in the "wrong" direction.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
jlun2: there are kill planes that will cause you to fall off the map, but they're generous enough to enable you to get really far away from the map without failing. In particular, I've seen a video of someone doing the last portion of Windy Valley unassisted, after having memorized the positions of the kill planes with a cheat code that draws them.
That said, I have no idea how Ice Cap worked.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
In 2 minutes there's 60*60*2 = 7200 frames. If it takes more than 7200 / 800 = 9 frames to sell 1 Zircon, then it'll take more than 2 minutes to sell 800 Zircons. And doesn't the Librarian manage to say "Hehe! Thank-" before getting cut off when you sell the next gem? That's gotta be at least a quarter of a second (15 frames), which would mean over 3 minutes of selling Zircons...
Or am I completely misremembering how gem-selling works?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Okay, as I understand things:
This run uses a glitch that allows you to scroll off the end of a character's inventory. They glitch the inventory of the first character (the guy with blue hair and a headband) so that values in the second character's status can be treated as items. In particular, the run achieves certain experience totals that correspond to particular plot items (the Nei items). Once all of these items are collected (and, apparently, a certain party member is stored in the house), the final dungeon can be accessed. Then the run manipulates luck to run away from the final bosses, which counts as beating them.
I'd like more details on exactly how all this works, though, as well as what the portraits on the right-hand side during the final dungeon are indicating.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
henke: Alucard is used to trigger a button from the wrong side using his teleport attack (debatable if this is a glitch since it seems very straightforward, but it's almost certainly not intentional). Then the Mines of Judgement are reached using some kind of out-of-bounds glitch, as near as I can tell. Otherwise it's a fairly "pure" run.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
