rdefabri
-
Posts
663 -
Joined
-
Last visited
Content Type
Profiles
Forums
Blogs
Gallery
Events
Store
Posts posted by rdefabri
-
-
1 hour ago, RockLobster said:
I've thought about your post again and have to ask for your case, why not just find an Atari 800 or other model?
Does this model hold some nostalgia or other value for you?
Well it’s the original 400 I purchased when I was 12 years old (I’m 55 now), so I’m not looking to get rid of it!
- 2
-
2 hours ago, DjayBee said:
I’m glad my thread inspired @vitoco to create the game - very cool! Now if I could only figure out how to do something similar on my own…
- 1
-
I'm an O.G. Atari 400 owner, purchased BITD. As others have said, immediately upgrade to 48K and a GTIA card if you can find them (I have no idea if any of this stuff is available). I never upgraded my keyboard, but that's always a nice option.
-
3 hours ago, Jetboot Jack said:
Yes...
Man would love to see that
- 1
-
1 minute ago, Beeblebrox said:
It's a real shame no one knows anything about the status of this game or know if it will likely be released.
If I can get my head out of my bum, and get it wrapped around the Adventure Studio, I have a few ideas similar to this. Would like to see this one finished though!! Is there even a prototype?
- 1
-
Rare I see an Atari game that exists on multiple platforms (C64, ZX Spectrum, Atari 2600) that isn't on the A8 line. Didn't realize Road Runner is ported to nearly all the other platforms BUT the A8. This one came out around 1985 I think, so the "heyday" was over, and certainly a big reason we don't have this one. It's not the greatest game, but kind of sucks since it is an Atari title.
- 4
-
13 hours ago, Allan said:
What magazine and issue was it in?
It's in the Compute! book referenced in a post above.
-
Has anyone actually typed in Front Attack? I can't find it, and if I copy paste the code, you lose the ATASCII characters.
I don't see an ATR or BAS file on Atarimania - it's listed as "MISSING".
-
1 hour ago, Preppie said:
Machine language subroutines are not allowed in the 10 liner BASIC competition.
It's possible to use strings to move players faster vertically but it's a little tricky and has a lengthy setup routine. Info can be found here:
Or you could design a game around your limitations eg. just have players move horizontally.
Yep I know you can't use machine language in 10-Liner, I kind of gave up on that until I can actually program something that works!
-
I forgot how simultaneously frustrating and enlightening programming could be (although I suck, so it's more frustrating than enlightening).
Creating PM graphics in Atari BASIC is simple enough - the POKEs to set up virtually everything, including horizontal movement, are all there. It's obviously vertical movement that becomes an issue, and standard practices yield a much slower moving sprite moving up / down.
There are known machine language VBI subroutines, and I can get them to work. However, I have some issues when I determine a collision (in this case, PM0 to playfield) - if I end the program, the PM stays on screen and when I go to run again, the program is corrupted and/or doesn't run.
So a few questions - is there a standard way to clear all the memory out and reinitialize? I've tried CLR, and even loops to zero out everything. No dice. The other question I have is that the VBI subroutines I've leveraged (mostly from Atari BASIC programming books) use lengthy DATA statements. Not a big deal per se, but if I were ever to attempt a 10-line BASIC game, it's a non-starter...is there some simplified or smaller machine code subroutine to handle fast vertical movement?
I know the simple answer is to use a different BASIC. BASIC XE and Altirra BASIC have built in PM commands that make it easier, but now I'm hellbent on doing this in BASIC. Any advice?
-
5 hours ago, vitoco said:
Sometimes I have to decide between X and Y features, because there is room for only one of them, and I keep the one that maximizes the gamplay.
Sometimes, while I'm writing the comments for the required explained source code, I find better ways to code something.
Sometimes I find that two statements could be reduced to just one with a variable that changes the behavior to the corresponding one.
Sometimes, when the order of the statements does not matter, I could make them fit better in the lines.
And sometimes I move to the next category and include all the features that I want...Moving to the next category might be an option. First I have to get this stuff to work - I'm a hack!
-
11 minutes ago, Preppie said:
If you post your code we may be able to give you some tips & tricks to help.
Still in the works. It's kind of a kluged up, Franken-code - just the way I seem to work! I have to get it operational, then I'll try to whittle it down. Right now, it's super inefficient and buggy.
-
I can't imagine how I can get my code down to 10 lines without some sort of magic. I might have to try a different category or language!!!
-
This is probably a dumb question, but if you have multiple DATA statements, is there a way to combine them? If so, I'm curious how the corresponding READ statements know which data to select?
-
Ok - there's a slight chance I'll have an entry, maybe in the PUR-80 category. The game sucks, but it's something, and the big if is IF I can get it down to 10 lines.
I don't stand a chance to win based on the entries so far, but it will be a bucket list item completed.
-
24 minutes ago, vitoco said:
In my BASIC tenliner games, I usally have a main loop with a global counter. Then, some subroutines are performed depending on that counter (a condition using a modulus function for instance). In that way, some routines are executed on each loop, some routines every other loop, or even the same routine using different "parameters" on each call. Sometimes, the routines are called based on an "is X element active?" condition. An X element could be a player, a bullet or even a sound effect.
You can look some examples in my BASIC tenliners page (Chase Me! is not there yet). Every game has its source code with comments, some in Atari BASIC, some in TurboBasic XL, and some in FastBasic.
This is kind of how I had the program structured. Main routine initializes the PMs, movement, collision detection, etc. Each turn has a physical change to the playfield, and I need that change to be "animated" or drawn. To do that, I would call a subroutine to each playfield change. Once the playfield is drawn / redrawn, it would return to the main program.
As I thought through it, because the subroutine has to slowly draw the playfield change(s), I began to wonder if that would stop / halt the main routine(s). For a counter - definitely. For PM movement, I'm not sure. Either way, the counter stoppage would be a problem as that's the main scoring mechanism.
-
I think the work around would be for every subroutine, the value of the counter is incremented within the subroutine.
It may make for some wonky timing (it doesn't need to be exact), but it could work.
-
27 minutes ago, vitoco said:
GOSUB just transfers the flow to another statement of the code, saving the position where the jump was done. There is no thread waiting for the subroutine to finish. At the RETURN statement, the flow leaves the subroutine and returns to the saved position and continues with the next statement.
Again, there are no multiple threads that could interact or perform tasks by themselves. VBIs and DLIs are another animals in the wild, not directly related to BASIC.
Then, if you have a main loop with a counter, you can only increase it after each GOSUB included in the loop is done, one by one.
Note that variables are "global" to the whole program. If you set a variable to a given value, then call a subroutine with GOSUB, you can use or update that value from the routine.
Yep, I knew this but was hoping there was some "trick", like doing something with the VBI. More I look at it, the more I realize how much more complex this is in BASIC. I'm sure there's some way but it's over my paygrade.
-
54 minutes ago, TGB1718 said:
In BASIC, it's essentially linear, the only way to do anything like that is to have a machine code
routine in the VBI, BASIC could interact with that routine, but you couldn't rely on the timing
without some sort of flag(s) passing between the VBI and BASIC.
Yep as I suspected. Everytime I think I've made a breakthrough, I hit a wall...gotta keep thinking through it.
-
My understanding of Atari BASIC is that it performs functions in a serial fashion (e.g, interprets a line, executes, goes to next line). Obviously, you can "interrupt" the flow with commands like GOSUB to run subroutines.
What I'm not sure about is how you can run certain functions in "parallel" (I'm putting "parallel" in quotes because I know it's not really parallel but to the human eye - it is for all intents and purposes). For example, if you initialize a PM, have it moving around a screen, then want to have a background drawn behind it, will that work? In this case (unlike my previous thread), I want the background to "build" - you see it drawn. Assume that's done in a subroutine, does the main program handling the PM graphic / movement / collision detection stop?
Take another example - you run a subroutine, but the main program has a timer. Let's say the timer increments every second, but the subroutine intentionally takes longer than a second to "build" / draw...does the timer not increment until you return to the main program?
I know there are orders of execution, but I'm drawing a blank, I feel stupid that I can't remember or figure this out.
-
39 minutes ago, Rybags said:
Digitized pics will only really look good in certain conditions or with certain modes.
APAC, TIP, RIP, HIP etc. RasterConverta pic, G2F.
Graphics 9 (luma only mode)
For something like Gr. 15 a mono pic in 4 shades could be made to work.
PC based graphics editors do have helpful tools like posturize to reduce number of luma levels.
A lot of this sort of thing is trial & error.
For the idea I have, even mono color would work. What wouldn't work is a slow load time of the screens, which likely makes hi-res (320x192) a non-starter.
The sample game in the Adventure Studio almost perfectly mimics what I want to do without the text choices on bottom. In that sample game, when you click to leave a room, a new room appears (almost) instantly. If you want to close the door, you see the door close - not really animated, but the effect is one where you have closed it and it visually appears that way.
I can get creative and minimize interactivity and animation / PMs, but to make this concept work IMHO, it needs some degree of both.
-
9 hours ago, MrFish said:
Give an example of something you'd like to use.
I think I’ve (sort of) found what I’m looking for. @ilmenit created a tool called “Adventure Studio” that allows for creation of graphical point-and-click adventure games.
The graphics can be created with RastaConverter and used in the game you create.
What I'm looking to do isn’t an adventure per se, but you would be in an environment that would require the player to click on different areas of the screen to access some sub-functionality or a different screen. The main screen would need to be semi-realistic, not something I could feasibly draw using Atari-based tools. I want to draw / paint it physically and “scan” it into Atari format. As I understand RastaConverter, it lets you convert a standard JPEG or other modern graphical formats and convert into an Atari format.
I don’t believe Adventure Studio is completed, but there may be enough there to get me started. I’m toying with it…gotta push myself, I’m easily discouraged but I’m giving it the old college try!
-
44 minutes ago, Beeblebrox said:
Sometime in 2021 or 2022 I'd heard there was interest from the developers of the game called Asteroida, the cause of lifes troubles (which BTW I've not since heard anything about) - to be taking the Adventure studio engine forward.
Check this out https://atarionline.pl/forum/comments.php?DiscussionID=5850&page=1
I had hoped that:
1) Asteroida, the cause of life's troubles - which looks a great point and click game - was going to be completed and finished
2) That the excellent Adventure Studio, which looks like an amazing engine for much needed colourful point and click games, would be finally realised.
I mean look at what it can do!!
Maybe both are still being worked on?
So Asteroida wasn't finished?
Point and click is pretty much exactly what I am thinking. I was actually thinking more of a keyboard actuated interface, but then remembered the Adventure Studio thread and now that I am looking at it, that's what I need.
-
So I think this tool would be perfect for the game I would like to create. Has there been any further development of it?
[WIP] MAFIA - port of a c64 game
in Atari 8-Bit Computers
Posted
Awesome! Thanks for doing this!