Jump to content

notanotheraccount1

Member
  • Posts

    8
  • Joined

  • Last visited

notanotheraccount1's Achievements

Tenderfoot Thahd

Tenderfoot Thahd (2/17)

  1. All I can tell you from my quick hack to enable a 2560x1440 in game resolution (rather than 1600x1200) is that I experienced some cosmetic glitches with it whereby player and nearby NPC's are not always visible when they should be depending on how the game area was centered or scrolled in certain locations. I am not about to try to reverse engineer things or take random guesses as to why this occurred, rather simply that was my experience with a naivé patch that changed 1600x1200 to 2560x1440 and nothing else. I presume these drawing issues do not occur for you in the release version and are in fact as a result of my hack to 2560x1440 as I patched my game (GOG release for what it is worth) early on about an hour into the game and just played thru the rest of the game in full widescreen. I haven't tested the other games you mention so I also do not know why those particular games would not have this issue also. I played through A2CS with my hacked version anyway because personally I would rather have the increased gameplay area and just deal with occasionally having to keep the game map scrolled a certain way in certain places to minimize the impact of the drawing issue I was experiencing. It was enough of an issue that I could easily see Jeff not shipping with 2560x1440 game area enabled unless he had a fix. Developers usually have pretty good reasons why they don't do something obvious like support 2560x1440, chances are it is not as simple to do in this case as my naivé attempt to enable it hoping that it was a mere oversight. [specifically for whatever reason I often had an issue when walking through the tower of the magi in the area suzanne hangs out if the gameplay area wasn't scrolled just right neither my character nor suzanne or others in that area would be visible. There were other places but that one always showed itself quite noticeably] For what it is worth I don't even think the PTK 2D engine framework/SDK exists or is supported anymore and I believe this is the particular software library Jeff chose to use for the underlying graphics engine handling the OpenGL layer so I would imagine he is having to try to maintain or work around issues in that codebase as well.
  2. yes I noticed that feature! It certainly reduces the support burden a game with this amount of detail probably generates but does so at the cost of, shall we euphemistically say, simplifying** away some of the mystery/puzzle/challenge of the game but it definitely is handy and holds your hand in case you "lose the plot"... Still doesn't fully address the completionist's issue, namely when you want need to get every spell at the highest level and get to all the blocked optional areas that are not directly related to any specific quest or overall plotline. **for the record I still think this series of games about reached its (non technical) high water mark back in the long ago days of the moving floors and various other similar intricate puzzles and mechanisms that I have long since forgotten but somehow vaguely remember or otherwise now ascribe to the original versions if that makes any sense. That said however, the latest versions of these games are clearly and obviously superior products in ways to numerous to bother enumerating other than to state its obvious from the visuals on down to the playability. If you have any doubt of that and want to try living in and idolizing the undeniably glorious past I claim to remember accurately just go ahead find a still working ancient Mac and just see how long you can last playing through the original versions from what 20-25 years ago! Apparently everything was better in the past and the problem with the kids today... except of course for all the stuff we absolutely take for granted now that has obsoleted our (now) hideous past that we have conveniently entirely forgotten about and are certainly unwilling to go back to in actuality!
  3. I guess as a future enhancement to the gameplay mechanics what I am suggesting is it would be awfully convenient if I could just click on a location I have visited on the world map and have it toggle the icon between multiple states or that let me attach a short custom note or choose a prebaked reminder of some kind. ie a list or way of indicating the remaining issue(s) with a location that roughly corresponding to these would do the trick for me: not fully explored can't read writing rock or weak wall blockage magic barrier blockage locked door/closed gate blockage too tough for now
  4. Specifically there are two particular spells that you need at a high level and that you cannot get until a significantly long way into the game that get you into many spots throughout the game where you have been otherwise able to do everything else already in the course of normal gameplay as the plot evolves. This is part of the "charm" of the game but I also find it frustrating in that it seems like busywork/bookkeeping that I have to manually keep track of very specific locations which I was quite sure I was unable to complete because of magic or physical barriers and locks that I was unable to bypass upon the first or second visits to a given place. Anyway yes, while you can manually take studious notes, if your the "completionist type" that just has to do everything everywhere has anyone got a better system? other than consulting one of the few lists/walkthroughs that I don't think even Randomizer has bothered to figure out and type up**? From my point of view I would like to be able to mark a given location on the map as apparently absolutely completed, 50%, 90% type deal since the main map now supports location markers. Similarly once you go through an unmapped portion of the game it should become mapped and have location markers of places you have discovered if you should ever go back there... ** that list would be, namely given a roughly optimal well specified playthrough order whereby you get the requisite abilities as soon as possible you then need to eventually go back to these exact 15 spots in some sane order to complete that location for all plot and character development/loot purposes... I will await randomizer's surely forthcoming exhaustive and authorative provably correct list within a few hours!
  5. I would like to suggest these sorts of possible changes be considered: 1 - anything that you add to your junk bag that is stackable should auto stack. 2 - the most recently added items should appear at the top of your junk bag and/or the bags contents should auto group and sort or be sortable in some intelligent and inherently useful fashion. 3 - there to be a keyboard shortcut to drop an item when your not outdoors - just like CMD clicking presently moves an item to your junk bag, why not option click an item to successfully drop it iff there is room on the ground? 4 - cmd clicking an item in your junk bag should move it to back to your inventory, iff (if and only if) there is an empty slot in your inventory of course. 5 - a way of dumping every instance of useless unstackable items, like say skulls, from my junk bag. ** 6 - consider making some items that presently don't stack like say Bags of Sugar stack rather than take separate inventory/junk bag slots. ** 7 - make potion ingredients not use any space in your inventory by just treating them as special items in future rewrites of the engine. **Personally I have no issues with just making everything stackable for inventory purposes and not worrying about "real world" physical constraints but some people might insist on having to make resource constraint micromanagement type decisions about which small subset of items is not junk with no real in game value. To me the junk bag mechanism already works around the inventory limitation so effectively all that is left is busywork of hauling the stuff you need out of the junk bag when you need it and not hitting sell all by mistake when its got your abacus, blank paper and the like in it...
  6. with the game in windowed mode (might also be happening in fullscreen mode but I can't recall right now) and taking a screenshot via Cmd+shift+3 or 4 I find that the game stops responding to further keyboard input. mouse/cursor input methods are still functional however and OS X's built in CMD+TAB application switching continues to work but the in game keyboard event handling stops working. Keyboard input works again once I have brought another application to the foreground and then switch back to playing A2CS, so this is an acceptable workaround for me. Not sure if this is happening for other people or if it is particular to my somewhat nonstandard setup, if this is not working for you a couple of independent confirmations would be all that is needed to confirm that there is known issue to look into.
  7. having spent a little more time playing the game in a hacked in 2560x1440 mode I see there are some cosmetic bugs with how drawing is currently being done in certain circumstances - namely my singleton character will sometimes not be drawn, and thus becomes cosmetically temporarily invisible to the player, when the map is scrolled so as to position my character in certain locations away from the central area of the screen. This would surely confuse most game players and detract from their in game experience as they just want to play a game and not deal with developer/alpha tester issues. This is not easy to describe completely or succinctly because it mostly seems to just be happening in an interior area of the visible game area somewhat towards the upper right of the screen but not actually extending to the edges -- undoubtedly this sort of issue is likely why the map game area is presently limited the way it is as any gameplay problems that creates ongoing support issues is a huge net negative for Jeff who is likely very busy trying to get the iPad version out to try to make some more money so he can keep on feeding the family and making games etc! My rough guess is the drawing, lighting, npc/player occlusion code simply doesn't seem to be robust enough to handle situations that were not tested or not designed in from the start. Ideally I would like to see the underlying game engine be updated to properly support arbitrary large window sizes but in a limited market with a one man shop there are priorities and constraints that simply generally do not enable the most robust and feature rich best theoretical software engineering practices to be used, especially at initial release. The games here are about the content first and foremost and much more is working acceptably and reasonably well than what is not working optimally for the relative few like those of us with 27" monitors.
  8. To clarify for those without access to large resolution monitors such as a 27" iMac display, yes the game runs properly in that it does not crash however the visually obvious problem Clocknova is citing is that the game doesn't make good use of the whole screen with game content when one is actually playing the game -- view his screenshots if your still unclear of the problem. I am also experiencing this issue on OS X as the game is presently hardcoded to set the active play area to a smaller fixed resolution (likely 1600 x 1200 in Clocknova's case) for some reason or other. This _seems_ likely to be a mistake or oversight as the game does actually _appear_ to run properly when the code is modified to actually use a larger active play area. Specifically I tested it at a play area of 2560 x 1440 and found no obvious problems albeit due to the way drawing of the game area is presently implemented you will experience even larger black areas in the corners of the active area (game screen) however you still get all the benefits of more game area on the screen at once. There are three in game "game area size" settings choices available once you launch the game past the initial startup dialog and the actual code contains particular sizes of 1600 x 1200, 1800 x1350, and 1280 x 960 if I recall correctly so that would likely be the extent of the currently supported game area sizes! The issue lies in the set_active_play_area_rect() code but unless your a tech savvy savage you'll have to wait for Jeff to address this with a proper update that enables larger play areas and/or an explanation why he chose not to do so. ----------------------- There appears to me to be an entirely separate issue whereby the red displayed content rectangle inset of the map window is not being drawn properly? It always shows a relatively tiny fixed sized square around my singleton character, in which case the only way this could perhaps be valid is if this is just supposed to be the immediately active area around my character rather than a representative rectangle of the drawn map area.
×
×
  • Create New...