Jump to content

NRV

Members
  • Content Count

    436
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by NRV

  1. This post: http://www.atariage.com/forums/topic/168077-interesting/page__view__findpost__p__2162770 has some info about that. I think that there are bugs also, but I never played a final version.. only copies.. and they had different version numbers, so I really don't know if they were fixed. Would be interesting to know more about the history behind this and the Eidolon..
  2. Right now, just 10K.. but there are ways to free some memory. Nop, but maybe you can influence the programmer if you try long enough .
  3. I like that one! Well, this engine is not that good for open spaces, the raycast cost starts being too high. Also with this resolution you don't see much detail if you are far away from a wall, so the "wolf3d" or dungeon/fantasy settings are the best suited right now (maybe robots or more "abstract" enemies.. the classic space station..). From a gameplay point of view I like having enemies, weapons and items to get, but I also like the idea of puzzles and other type of "special items".. (a "portal" like game?, magic?, switches and traps?, mazes that change shape while you are watching?.. I almost did that). But is just too soon to decide. Maybe with a more advanced engine, in the future, "someone" other than me could start making another type of game Regards.
  4. Right now the answer is "yes" to both. But... I think I could have walls of smaller height (not bigger) than the "normal" ones, without too much changes. The problem would be that ,still with that, you wouldn't be able to see through the "top" of the wall. I mean.. assuming a "low" wall goes from the middle of the screen to the bottom, the raycasting right now would stop at the first wall (and the top part will be drawn just "empty"). As a general solution, I could implement "windows", parts of a column that let the raycasting continue (to get "arches" like AR: The Dungeon, for example), but that would be a little more complex and hit the frame rate (in those parts). Right know I'm calculating intersections only for the border of the tiles, because I have precalculated steps and distances for every ray angle, per tile. That's why the "90-degree angle only" and also why I don't have the doors in the "middle" of the tile (like in Wolf3d). Implementing the middle horizontal and vertical lines inside a tile could be possible.. also the diagonals between the corners of a tile.. more than that, like a free angle, will be more like another engine (I haven't thought much about that specific case). I hope he understand what I'm trying to say.. if not he can always ask more questions Regards!
  5. Yes, that was what I was thinking, but changing the display list through a DL JMP instruction at the start and at the end (pointing to another DL code that jumps back to the normal display list). I cannot just simply add lines at my screen memory because I'm using a double buffer of 4K each, and need them both to be consecutive (they have their lines interleaved also). Also I have one LMS per scan line, so I can not just change the first one and forget about it . Maybe I could use VSCROL in every line, but changing the DL is not that complicated.. (ooops.. forgot about the DL JMP black line effect.. cannot do that for the jump back at least.. maybe should have a lot of DL single blank lines and write over them when needed.. VSCROL is looking nicer right now )
  6. Sorry, you mean the pictures? That's only an example drawn in Paint. Maybe I can hard code a new view point height (different to the current "middle height" one), but my point was that I cannot change between different view points in real time (right now). If you were talking about changing the display list, I hope so.. Regards. (About the "night-view" mode in other post.. if for the entire screen and without textures it should be easy to implement, it's just selecting a green color for all screen and using new luma values for the "depth cue" mode).
  7. Thanks! I don't know exactly what "that one thing" is, but please continue with it and publish it in the not so far future. That would be something, but maybe is a little to much to ask The head bob has been in my wish list for some time. The normal "hack" of moving the whole screen up and down should be easy to implement, maybe just changing a little the display list. The (most) correct way, of moving the point of view up and down, would be impractical for me right now, because my "write texture column" methods are hard coded to write at certain positions (heights) of the screen area. Moving the point of view up or down, basically has the effect of moving up or down the positions of every wall column, but the displacement is bigger if the column is far away. The limit cases are with the point of view at the top of the screen (all wall columns should start at the top then), and with the point of view at the bottom of the screen (all wall columns should end at the bottom).
  8. Wow, I will try to catch up to all comments That will be a problem then, because it sounds like you need to change COLBK and PRIOR at the same time then.. maybe could sacrifice a player or missile to cover the borders. It was a fast test, I only changed the display list to mirror the top area (the engine is still drawing all the screen, you just don't see the lower half). I will try to do a proper "speed" test later. But about the memory, from what I see I could free at least 4K from the display, like 4K from textures and like 7K from code. I will try at some point the use of gr.10, but I don't believe it will look good with the "half a pixel" displacement (but I can be wrong). I was also thinking of using it as a replacement of gr.11 (the color part), with this I could change colors by DLI, change the background color or do some simple color animations on the fly. It can be also used to replace the gr.9 lines, but that will be less useful in my case. Anyway, I don't like the restrictions that this could impose over the P/M colors. At this point I support the use of textures with columns of different colors, but I'm not using any because they don't look that good.. so probably changing the color at the middle of the screen also wouldn't look good for textures. I think all experimentation is "valuable". I still want to do the best I can in 64K and for now I still have memory, so I don't want to use the mirroring, I like very much how things look right now. But, if someday, the ONLY WAY to have something playable in 64K is using mirroring, I will probably use it (but still wouldn't like it , textures will need a lot of work to look good there), or maybe as an option for people who don't mind. In that case I will have also a version that run from cartridge, on all machines with 64k, and a version that runs in a 130XE (for people that don't like cartridges ). I don't believe I would need more than 128K. The idea of having different "render paths" is not that difficult to implement. Could save space for more textures. The problem right now is that the texture code is the section of unrolled code that eats more memory from my "design", so adding this in 64K is impractical. Thanks Miker, they look good: I suppose you changed the display list to add or remove a scanline (the same change I did in PM 1.5 should still work), the only problem is the "hud" effect, but that is a minor detail (also the gold items look a little different, but I suppose that's an Atari800Win "thing). All correct. But just a few thoughts: + not everyone likes to have a cartridge (remember that poll?) (and self modifying code on cartridge is hard... ) + more memory usage means less user range: 128k? 320k? 512k? 1MB? + more memory usage doesn't mean better programs (remember that huge karateka demo?) + programs which won't work on a stock 130XE are not allowed to participate the ABBUC contest + I appreciate 'Space Harrier' but at least now, it doesn't seem to run without cart + using much memory for something isn't retro - I could digitize 'Gone with the Wind' to APAC, building a huge ROM. But what does it show? + I don't care, but C64 guys will start complaining if leaving their limited 64k view of the A8 + using our 'co-processor' ANTIC to speed-up visualization or allow other neat things AND additionally save memory IS cool and something other machines can't! + remember 'Bomb Jake' and the problem of some users to load big files? The compressed version was very appreciated. I agree with a lot of these points - the cartridge is an "old" standard used a lot in the Ataris and the old game consoles. - in these days (at least for me), programming in these machines is about the limits.. the possibility to optimize to the very end and see how good you are at getting the best solution (this also applies to the "gameplay" part of the equation..). - an Atari for me means 800XL and 64K (that was what I knew). Contrary to all the evidence.. I'm not trying to do a port of wolf3d (yeah, I know ). I like to create "new" things, so if I can (and get to that point) I will try to do something different AND better . Anyway, right now is all speculation. I return to work in one week and probably wouldn't be able to advance at the same speed of the last month (but I will try ). Regards! (some development screens)
  9. I don't know if I understand it correctly, but at least in the emulator, if I change COLBK to 2, I get something like this: The change is visible when alternating between GTIA 9 and 11 inside the IRQ.. and also it seems the "luma resolution" is lower.. is that the expected result? I change the color in COLBK in the "attract" mode (don't press any key for some minutes to see it), but that look good. By the way, I did a fast test mirroring the screen and got this: I suppose that with some texture planning it could look decent.. and I should say that using it would be a big boost to the frame rate and a great memory saver. Thanks for the nice review Kaz One more "hint" (you can get to the 4th and last level with two keys):
  10. haha sorry, I hope is not "my" fault here, a little help: Yeah.. the Alternate Reality (the city) "way".. I'm still resisting to it But it's an option.. the only problem is that it will force me to use the same colors for the floor and the ceiling (hmm.. I could have some mirrored software sprites also.. like columns).
  11. Let me add a working enemy and let's see what we can do In reality, I have an idea for another raycaster that will be better suited to that kind of "dungeon" game. As much as I like this one, I believe that the "sweet spot" for this "technology" is other graphic mode, with proper pixel resolution, fewer screen columns, less texture detail and with lot of "light effects" (depth cue, reflections?, some kind of bump mapping for walls?).. hope to get that working someday I get that a lot The version without intro only needs 44kB. I suppose it is a non-crunched file. (EDIT: After still thinking) However, I also suppose the free 18kB is needed for unpacking unrolled routines & other workspace, gfx memory etc? The intro start loading at 16K and later the main game just overwrite all of it. The main program uses all memory from 10K and up, so you need at least 52K to run it (8K of those are the double buffer screen area). I'm not using any kind of compression yet. Great! someone saw the "dark" levels (I hope that the second dark level will be very scary if I add some enemies.. by the way that was a fast hack, the engine is doing the same work that with the "textured" levels, if programmed correctly those levels should run at a very good frame rate). Sorry the corridor level is the last one and is mainly there to get the last treasures, and to show a long "matrix-like" corridor with the engine . At the start I had only the first level (a maze of 32x45 tiles) and I wanted to add more levels, but don't have enough memory. So I created some kind of "language" to generate mazes by code. The maps 2,3 and 4 have areas of 28x20, 31x19 and 26x10 tiles, but use only 131, 137 and 86 bytes! There are 4 secret "areas" in the first level with some of them already in the videos (one "area" can have more than one secret..). There are only 2 keys hidden, but you only need the second one if you want the high score . Yes, they are consecutive colors. The green is in reality a "blueish-green", I should have used a proper green I suppose. Many years ago I used to think that all things should run at 60 (50 in PAL) frames per second, if not they were not "valuable".. and then I saw Space Harrier running and it opened my eyes I should say that this project was a constant "surprise" for me. I started with a "what if..", trying to do things that I didn't know if they were to work at a decent frame rate.. and they worked! every one of them.. I don't know if I should talk about luck here The other day I was starting to think that maybe something like doom, but without textures, will be possible (that and like 10 other projects that I have in my head..) By the way I still have an optimization to add that could give a boost to the frame rate. Is a little complicated because of my last changes to the code, but worth a try if I want to implement another kind of raycasters later. Basically it consists in tracing the rays not form left to ray of the screen, but applying a kind of "binary search" to the process. Is based in the fact that if 2 different rays collides with the same wall, you know that all the rays in between those 2 rays collides with the same wall. So you can interpolate the final height for those columns (you still need some calculations to get the texture coordinate, but you can do them a little faster also). Try holding [shift] when the loading ends and the main game start, to see a better frame rate working! Regards and Merry Christmas to all!
  12. Ooops.. i forgot to post a link here, for the people that don't go to the programming forum http://www.atariage.com/forums/topic/174274-project-m-20/ and I should add something for the people that already knew.. try holding [shift] just when the main program ends loading (or hold it while loading, just to be sure).. that's "turbo" mode, for people that like a fast frame rate, over other things. Regards!
  13. haha I'm looking at Altirra 1.9 with a "motherboard temperature" option..
  14. Again, thanks Hehe.. is very exciting for me to see videos from real Ataris, I don't have a working machine right now, thanks for them!. Also, is good to see that the NTSC version also looks good in real hardware. There are some secrets and "surprises" yet in this demo . There is a teleporter to another level.. try to find it. Yes, I used 3 songs from Miker. The one in the intro use 4 channels, but the other two can only use 3 channels!, so is a greater achievement Yeah, I think the same. I should be playing this thing, not programming it Seriously, I believe that there was a lot of potential in the idea of making cartridges with more memory (that run in all machines), like the NES "upgrade path", but sadly , it never happened. About the PAL artifacting I have more questions than answers. I use it like that, a color pixel (with intensity 0), in a GTIA 11 line, gives its color to the pixel in the line below (a pixel with any intensity, but with color 0), in a GTIA 9 line. I don't know if pixels of different colors also blend (and if the new "blended" color also affects the pixel below..). If that's the case then you can also generate new colors outside the normal palette (the Altirra implementation seems to do this). haha sorry, my description was based in the standard palette for PAL in Altirra, please adjust your emulator or TV set That's the idea, for PM 3.0 About the engine, right now is running in 64K and I have like 10K free, more or less. I could probably free another 4K or 6K, with compression and removing some things (I'm still using a double buffer of 4K each).That would come in handy when trying to add enemies and real sprites. I was looking at the SNES version of wolf3d the other day, and they seem to have a lower texture detail, so maybe I will try to reduce vertical resolution in half, freeing another 4K. Right now I will try to add enemies using Player/Missiles (instead of precompiled software sprites, like in PM 1.0) and see what I get, but I'm confident that I will get it one way or another. hehe sorry, wasn't my intention.. if you get the key in the first secret area, after that you only need to avoid areas with green doors that doesn't give you a key in return.. with that you should be able to get to the end of the level When you say "hang" are you talking about a real machine? remember that the PAL version only runs in PAL and the same for the NTSC version. If not tell me if is something I need to fix Regards! (just noticed this comment from PotatoHead: "I only have 800XL... stuff like this makes me want a full real machine setup. One day soon, I guess!" and from another forum, some people seems to think that it requires more than 64K.. it's not the case, just try it in a normal 800XL ) (@Jacques: I know, but I still want to do the best I can with 64K first )
  15. Thank you all Just updated my post! Yeah, you need to use the last Altirra 1.8.. there the IRQ sync is fixed by Phaeron. I could make a version for Atari800Win, but it will only run there. The single pixel noise.. Phaeron warned me about this , it seems that there are two different types of atari computers, and there is a one cycle difference between the IRQ start between them. I can make a version that run well in your machine, but I was waiting to have a better knowledge to do a version that do the correct initialization, auto detecting the kind of machine where it's running. Regards!
  16. Hi all! At last, after a year of doing nothing, I got some time at the end of this year to advance this thing (a long vacation!). After like a month and a half of "casual" work I got to the point where you can move freely through the maze(s), and also added a lot of details and tested some ideas. There are 2 versions: PAL and NTSC, they only run in the correct machine and are almost equal. The colors are adjusted to be similar and the music plays at the same speed (NTSC drop one of every six music steps, but it sounds pretty good). The PAL version is the better one because of the PAL artifacting and the "longer" frames, but in general they are pretty similar. Try this in Altirra 1.8 for the best results. For PAL you need to select in "System->Video": "PAL" and "PAL artifacting". Also in "Adjust colors" the preset "original". For NTSC unselect "PAL" and select the color preset "Authentic NTSC". I had not tested this in real machines, but I cleaned up the code so not to load anything below the 10K mark, so I hope this helps those with modern load devices. I added a little intro, mostly to showcase the great music from Miker . Many thanks as always for all those songs! Basically, now you can move through the maze, picking up keys and some gold treasures, opening doors and founding secrets. There are no enemies or "visible" sprites yet, so I added a "graphical" way to show that you picked up something (anyway I generally put things near golden walls.. I'm not that bad a person ). There are 3 types of doors: blue ones are free, green ones need a key to open and red ones cannot be opened. Try to use "wisely" your keys (yes, right now is mostly trial and error..) and try to end the "game" with more than $600! (well, there is not really an "end", is just the last maze ) I implemented different methods of control, so you can choose the one that fits you better: -> by joystick: up/down moves forward and backward, left/right rotates, button+left/right strafe to the sides, button while looking at a door (needs to be at the tile beside the door!), opens the door. -> keyboard: - arrows (with or without [control]) and W,A,S,D: moves and rotates. - [shift]+left arrow/right arrow: strafe left right - Q and E: strafe left right - Z and X: strafe left right - [space bar] or [return]: open doors (In emulation, in a PC keyboard, I like to use the arrows and Z,X to strafe) -> other keys: [control]+M: music on/off [control]+R: rotation speed (between 1 and 5) [control]+P: old hud effect plus a "classic" vcount rainbow Right now there is no restart method, sorry for those that play in real machines . Technical post and spoilers later Regards! project_M_2.zip
  17. haha ok ok I'm going to post the files first and edit the post after that
  18. Well, at last.. Yesterday night the "release candidate 1" was ready, but I needed to sleep So.. now, after having breakfast, expect news in about one hour. I need to test all things and write a long post. Regards.
  19. :thumbsup: thanks for all the hard work, for me this a great tool. (all versions of project-M likes Altirra 1.8 )
  20. Ooooh.. really nice They seem to be the same ones, with all the info. Thanks, I 'm going to abuse of the google translator.
  21. I knew it! Speaking of the video.. that was the "lame" way to lose a pack inside the ship with the robot haha (not that it happened to me..) I always wanted to have a guide with pictures of all the ships and an explanation of all the races and parts in that game, the manual doesn't have much info.. anyone have any idea if something like that exist? I know that the map of the levels are in some site, I have the pictures somewhere. About the parts I remember generators that let you move faster, better (and different) shields and weapons, two radios (that played music!.. one of them was the melody from ballblazer), things like heavy weights (that make you very slow), a map of the level that let you track ships from different types (races?), etc. Also, I remember getting to level 20 but without being able to finish the game, was that possible in the final version of the game? (does that version exist?!?) Regards.
  22. Yes! I suppose my factor was more like 3.5 anyway But that was because I had some fun adding a lot of "little" details.. and I could continue doing that for some weeks, but now is time to let this "child" go.. With a little luck only one more day. Regards.
  23. doesn't seem overkill (what? you are working instead of doing your next demo? can we have everything?? )
  24. damn! I clicked the link hoping to see something cool.. hmmm.. too much weeks being the "next week", should be this one or at most the start of the next.. the problem is that I'm having fun adding things these are the previous links: http://www.atariage.com/forums/topic/148697-project-m-stage-1/ http://www.atariage.com/forums/topic/152979-pm-1-5/
  25. Congratulations for your first place! This is a really great demo. Personally, I like a lot the effects, the music, the graphics and the "cohesion" between all the parts (and probably I would like the code if I take a look at it ). The only "hard" part was trying to read the greetings . Yeah! please provide any info about that and about the 256-dot matrix with "depth cue" . Can you change charsets midline with pixel resolution? inside a char? or are you limited to a char resolution and use the black line to cover some parts? Can you apply that to changing colors midline, inclusive in bad lines? Regards!
×
×
  • Create New...